Subject: Cert Path Validation Bug in pkix-new-part1-00

From: "Pawling, John" <[email-masked]>
Date: Fri, 25 Feb 2000 17:07:57 -0500

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
[email-masked]
============================================

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Feb 2000 10:58:41 +0000

John,

Your new text seems to prevent parameter inheritance 
across an "algorithm gap", e.g. the following couldn't 
verify (because we set the working parms to "null"
during verification of cert 2, so cert 3 will fail):

1: [ top-CA, top-CA, DSA + parms] (self-)signed with DSA/SHA1
2: [ mid-CA, top-CA, RSA + NULL ] signed with DSA/SHA1
3: [ low-CA, mid-CA, DSA (no params) ] signed with RSA
4: [ end-entity, low-CA, whatever] signed with DSA/SHA1

(the notation is [ subject, issuer, subj.public key] signing-alg )

I've no problem with this, but it might not be what an 
implementer would do, so should it be made explicit?

One way to do this might be to include a statement like
"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".

This would make cert 3 above non-conformant.

The text could go into section 4.1.2.7 or section 7, or maybe
both.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Pawling, John" <[email-masked]>
Date: Tue, 29 Feb 2000 11:29:28 -0500

Stephen,

I agree that the handling of RSA parameters isn't clearly stated in the
pkix-new-part1-00 cert path validation procedures.  Recommend that the
following text be added to the description of the
working_public_key_parameters variable in section 6.1.2, bullet (i): "The
RSA algorithm parameter is ASN.1 encoded in the RSAPublicKey SEQUENCE
conveyed in the subjectPublicKeyInfo subjectPublicKey BIT STRING.  The RSA
algorithm parameter is always present in RSAPublicKey (algorithm parameter
inheritance is not used with RSA).  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.  This strategy is used because the RSA algorithm
parameter is always bundled with the RSA public key in the RSAPublicKey
SEQUENCE."

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 29 Feb 2000 19:01:21 -0500

John:

I have been scanning this thread.

Please note that there is no such thing as parameters in the RSA.  The
public key is e, n.  n is the composite and is not common to all the folks.
While there are some popular values of e such as 3 and 2**16 + 1, it is the
encryption exponent and not a parameter a la DH or DSS which can be a common
to a community and in DH's case is required to be common for the crypto math
to work.

Thus, in my mind from pure cryptographic algorithm and from X.509 viewpoints
talking about RSA parameters is a contradiction in terms.

-----Original Message-----
From: Pawling, John [mailto:[email-masked]]
Sent: Tuesday, February 29, 2000 11:29 AM
To: pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00

Stephen,

From: Santosh Chokhani <[email-masked]>
To: "'Pawling, John'" <[email-masked]>, pkix <[email-masked]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Tue, 29 Feb 2000 19:01:21 -0500

John:

I have been scanning this thread.

Please note that there is no such thing as parameters in the RSA.  The
public key is e, n.  n is the composite and is not common to all the folks.
While there are some popular values of e such as 3 and 2**16 + 1, it is the
encryption exponent and not a parameter a la DH or DSS which can be a common
to a community and in DH's case is required to be common for the crypto math
to work.

Thus, in my mind from pure cryptographic algorithm and from X.509 viewpoints
talking about RSA parameters is a contradiction in terms.

-----Original Message-----
From: Pawling, John [mailto:[email-masked]]
Sent: Tuesday, February 29, 2000 11:29 AM
To: pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00

Stephen,

Date: Tue, 29 Feb 2000 14:56:39 -0500 (EST)
From: Robert Malick <[email-masked]>
Sender: [email-masked]
To: "[email-masked]" <[email-masked]>
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?

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

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.

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?

	Robert Malick
	National Institutes of Health

From: "Pawling, John" <[email-masked]>
To: pkix <[email-masked]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Tue, 29 Feb 2000 11:29:28 -0500

Stephen,

Date: Tue, 29 Feb 2000 10:31:39 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Pawling, John" <[email-masked]>, pkix <[email-masked]>
CC: xme <[email-masked]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00

Hi John,

> I respectfully disagree with your comment that
> my new text prevents parameter inheritance across an "algorithm gap".  
...
> Therefore, the cert path verification software does not need to set the
> working_public_key_parameters to the RSA algorithm parameter value

Fair enough, but that isn't clearly stated, so maybe there should be 
text about special handling of ASN.1 NULL ('0500'H) as a parameter? 
But in any case...

> I agree with you that cert 3 in your example is invalid because the DSA
> parameters must be present if the cert is signed using RSA.  The
> verification of cert 4 would fail because working_public_key_parameters
> would be set to NULL based on cert 3.  I agree with your recommended text:
> "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."

...that was the meat of the posting, so we do agree!

Regards,
Stephen.

Date: Mon, 28 Feb 2000 22:54:52 -0500 (EST)
From: Rich Salz <[email-masked]>
To: Ambarish Malpani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP

> If a. is true, then you really need to send the whole cert to the
> VA and have the VA tell you if it was actually issued.

Or a hash of the cert.  The CA could generate an "issued list",
perhaps a signed sequence of hashes, and the OCSP Responder
could see if the hash the client sent was in the CA's whitelist.
(Unfortunately that area is rife with patents.)

> If b. then all you need to do is verify the signature on the cert
> and you are done - having the VA check for the cert in a directory
> is useless.

No -- see below.

> If I can get a level of security by relying on 1 component, I would
> prefer that solution, to one where I get the same level of security
> by relying on the security aspects of 2 components - the more
> pieces you need to be operated securely, the more insecure you
> solution.

Not necessarily: it depends on what "securely" really means.  If the
two components are under different domains of control, then you could
get greater security even if the level on each component is low.
In the above case, if someone has bribed a CA's overnight operator to
improperly sign a certificate, they'd presumably now have to spend
twice the amount of money to get the cert into the directory.  The
directory could say "we only accept certs after getting a phone
call from Mike Jones between 9am and 5pm."

	/r$

From: Ambarish Malpani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Mon, 28 Feb 2000 14:06:14 -0800

Hi Rich,
    Answers inline.

Ambarish

> -----Original Message-----
> From: Salz, Rich [mailto:[email-masked]]
> Sent: Monday, February 28, 2000 2:03 PM
> To: 'Ambarish Malpani'; [email-masked]'
> Subject: RE: German Law and OCSP
> 
> 
> >c. The responder (VA) verify that the cert was contained in "the"
> directory.
> 
> Is VA now a generic term for OCSP responder?  I thought you 
> guys trademarked
> it. Be careful, you don't want to go the way of kleenex... :)

Actually, I am not sure that we have done so - good idea :-)

> 
> >ANOTHER CERTIFICATE WITH THE SAME
> >SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!
> 
> How so?  Since the certID includes the issuerNameHash, it 
> identifies the
> issuer, and since the issuer doesn't re-use serial#'s,...  There are
> performance impliciations -- it might require a directory to index by
> HASH(issuer_dn) -- but that seems surmountable.  There are 
> other approaches,
> such as having an OCSP responder which gets both certs and 
> crl's, not just
> revocation data.  (Modesty prevents me from naming names :)

Yes, Rich - what you say would be true if nobody could forge a
CA's signature, but in that case the person making the request
could just verify the signature on the cert itself and you would
not get any added benefit from having the VA look up the directory
for the existance of the cert.

The point I have been trying to make is:
a. Either you think the CA's signature can be forged
b. Or, you don't.

If a. is true, then you really need to send the whole cert to the
VA and have the VA tell you if it was actually issued.

If b. then all you need to do is verify the signature on the cert
and you are done - having the VA check for the cert in a directory
is useless.

> 
> It also puts the directory into part of the trusted base.  In general
> directories aren't put there, but if that's what the lawyers 
> wrote, then
> we techies can only comply.

Again, as a techie, I like to make my own life as simple as I can.
If I can get a level of security by relying on 1 component, I would
prefer that solution, to one where I get the same level of security
by relying on the security aspects of 2 components - the more
pieces you need to be operated securely, the more insecure you
solution.

Hope this clarifies things,
Regards,
Ambarish 

From: "Pawling, John" <[email-masked]>
To: pkix <[email-masked]>
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00
Date: Mon, 28 Feb 2000 17:08:03 -0500

Stephen,

Thank you for your response.  I respectfully disagree with your comment that
my new text prevents parameter inheritance across an "algorithm gap".  As
stated in RFC 2459, Section 7.3.1, the RSA algorithm parameter is ASN.1
encoded in the RSAPublicKey SEQUENCE carried in the subjectPublicKeyInfo
subjectPublicKey BIT STRING.  Furthermore, the RSA algorithm parameter is
always present in RSAPublicKey (algorithm parameter inheritance is never
used with RSA).  The pkix-new-part1-00 cert path validation procedures never
specify that the working_public_key_parameters variable be set to the
algorithm parameter associated with an RSA public key.  This is true because
the subjectPublicKeyInfo algorithm field associated with an RSA public key
always contains NULL parameters.  

I believe that the section was purposely written in such a manner.  I agree
with that strategy since the RSA algorithm parameter is encoded within
RSAPublicKey and is always present.  Typically, the cert path verification
software passes the RSAPublicKey SEQUENCE to a low-level crypto library
which decodes the SEQUENCE into the modulus and publicExponent components.
Therefore, the cert path verification software does not need to set the
working_public_key_parameters to the RSA algorithm parameter value, because
the low-level crypto library always has access to the RSA algorithm
parameter in the RSAPublicKey SEQUENCE.  Given that assumption, the
pkix-new-part1-00 cert path validation procedures (with my recommended text
included) correctly support parameter inheritance across an "algorithm gap".
This assumption should be included in the definition of
working_public_key_parameters in the pkix-new-part1-00 cert path validation
section. 

If people disagree with this assumption, then the pkix-new-part1-00 cert
path validation procedures need to be re-written to specify that the
working_public_key_parameters variable must be set to the RSA algorithm
parameter present in RSAPublicKey.  This will cause the procedures to be
algorithm specific (rather than generic).

In your example below, the verification of the RSA signature of cert 3 will
succeed because the cert path verification code knows that the RSA algorithm
parameter is encoded within RSAPublicKey and it ignores the
working_public_key_parameters (set to NULL at that point).

I agree with you that cert 3 in your example is invalid because the DSA
parameters must be present if the cert is signed using RSA.  The
verification of cert 4 would fail because working_public_key_parameters
would be set to NULL based on cert 3.  I agree with your recommended text:
"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."

-John Pawling

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Monday, February 28, 2000 5:59 AM
To: John Pawling; pkix
Cc: xme; RussHousley; TimPolk
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00

John,

Regards,
Stephen.

From: "Salz, Rich" <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Mon, 28 Feb 2000 17:02:34 -0500

>c. The responder (VA) verify that the cert was contained in "the"
directory.

Is VA now a generic term for OCSP responder?  I thought you guys trademarked
it. Be careful, you don't want to go the way of kleenex... :)

>ANOTHER CERTIFICATE WITH THE SAME
>SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!

How so?  Since the certID includes the issuerNameHash, it identifies the
issuer, and since the issuer doesn't re-use serial#'s,...  There are
performance impliciations -- it might require a directory to index by
HASH(issuer_dn) -- but that seems surmountable.  There are other approaches,
such as having an OCSP responder which gets both certs and crl's, not just
revocation data.  (Modesty prevents me from naming names :)

It also puts the directory into part of the trusted base.  In general
directories aren't put there, but if that's what the lawyers wrote, then
we techies can only comply.

Date: Mon, 28 Feb 2000 11:17:48 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: <[email-masked]>

Anders,

What part of my comments re the context in which this WG operates 
were unclear to you?  I already pointed out that we have, in 
producing 2459, been willing to disparage common practice wrt misuse 
of DNs.

Steve

Date: Mon, 28 Feb 2000 11:28:29 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Cc: "[email-masked]" <[email-masked]>

Tom,

My favorable reaction to this proposal is based on the assumption 
that the SubjectAltName would be a valid DN, and thus one need not 
impose any special interpretation on the use of serialNumber in that 
name.  So, for example, I would expect an name of the form: C=SE, 
O=National ID Card System, SerialNumber = 123456789.  This is 
consistent with the usual definition of the SubjectAltName extension, 
and merely suggests that this DN is an alias for the other entry in 
the DIT.

Remember, my suggestion was an effort to respond to a perceived 
special case ID requirement, which is not one of my favorite topics 
in the first place ...

Steve

Date: Mon, 28 Feb 2000 10:58:41 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: John Pawling <[email-masked]>, pkix <[email-masked]>
CC: xme <[email-masked]>, RussHousley <[email-masked]>, TimPolk <[email-masked]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00

John,

Regards,
Stephen.

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Sat, 26 Feb 2000 08:55:10 -0000

Steve,

<snip>

>Finally, Anders, this does nothing to address your more recent desire to impose the
>concept of a naming domain on DNs. Since DNs exist in the context of a DIT, which
>establishes naming domains via hierarchic refinement (the same way the DNS does), 
> suspect that what you are asking for here is not consistent with the use of a DN anyway. 
>Maybe we're back at the "have your cake and eat it too" stage for this issue.

>Steve

In the X500-world DNs exist in the context of a DIT.  However, most PKIs are
X500-compliant only with respect to certificate format .   Also I doubt that many X500-
compliant systems use certificates without fully qualified DNs.  I.e. my request
probably matches >90% of all certificates.  That figure justifies some kind of support.
Now I'll go back a continue eating that cake.  It tastes fine!

Anders

From: [email-masked]
To: Stephen Kent <[email-masked]>
cc: Anders Rundgren <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 25 Feb 2000 19:22:27 -0500
Subject: RE: Straw Poll: SerialNumber definition

     There is one point about Bengt's method which I am slightly confused
by.  Let us suppose that the normal method of putting a unique identifier
for a user into a certificate is by creating a subject alternate name with
a DN consisting of the DN of an assigning authority (most often a country,
an organization, or an organizational unit) followed by a serial number
alone in an RDN.  Does this mean that all DN's in alternate names are to be
interpreted as unique user identifiers, or only all those DN's in alternate
names whose lowest-order RDN consists solely of a serial number?  If the
latter intepretation is accepted, relatively few existing certificates
should be broken.

          Tom Gindin

Date: Fri, 25 Feb 2000 17:53:08 -0500
To: Anders Rundgren <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Cc: "[email-masked]" <[email-masked]>

--============_-1260603158==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>You are free to continue to outlaw DN interpretation support schemes 
>(should include the latest
>suggestions by Stefan and David Kemp) in the same way as dnQualifier 
>in spite of the fact that
>both belong to current practice and work just fine.

Irrespective of the technical issues we are discussing, there seems 
to be some confusion about the purpose of the IETF standards process, 
and of this WG's charter.

It is NOT the goal of this WG to produce standards primarily based on 
current practice.  If that were the case, we would not have 
depricated the use of the Common Name as a means of expressing an RFC 
822 name or a DNS name.  There is considerable common practice here, 
but its inappropriate and thus 2459 strongly encourages use of the 
appropriate name forms and discourages misuse of the DN name form in 
this fashion. So, I think that we have established the flavor of what 
PKIX tries to do in this regard.

The charter of PKIX stated that we were profiling X.509 standards for 
use in the Internet, extending such standards as needed to meet 
Internet needs.  Sometimes we diverge from X.509, when we think it is 
absolutely necessary, but we usually work with the X.509 folks to 
achieve compatible solutions.  The proposed change to the definition 
of serialNumber is such an example, and, in the recent past, the 
change to the basicConstraints extension.  So, we do take issues at 
times with what X.509 does, and we work to resolve such problems, but 
we do not do so lightly.

The issue that triggered this expending debate was the observation 
that an ID number assigned as part of a DN used in a QC might, in 
many instances, uniquely identify the subject. Moreover, an RP would 
like to take advantage of this feature to compare two QCs issued with 
differing DNs, but by the same CA, to determine if the same entity 
was represented by them, despite differences in the DN.  I can 
appreciate the desire to be able to make such a comparison, but I 
also note that this comparison approach clearly assumes knowledge 
outside of the DN semantics.

What we have here is a desire to have one's cake and eat it too :-). 
You want to make use of the DN syntax because of the ability of 
existing software to parse DNs, but the semantics of what you want to 
express is not really a DN. In other instances we have defined new 
objects to represent other name types, but here, since name would 
make use of the same attributes, it seems less critical to define a 
new object under the GeneralName  structure. The challenge is to 
consider way to resolve this issue, without breaking the existing 
semantics of DNs and while minimizing the need to create new 
software. Fortunately, i think we have a porposal that does that, as 
explained below.

Tom Gindin posed a good set of questions that are related to the 
issue I described above, but also are somewhat independent. I think 
the redefinition of serialNumber addresses the fundamental concern he 
raised.  However, this redefinition, although it allows a unique, 
national ID to be represented, does not change the semantics of a DN 
in support of the comparison goal described above.  To know that a 
serialNumber attribute has the property of uniquely identifying a 
subjetc, all but itself, one has to communicate this in some fashion 
to software operating for RPs.

Dave Kemp provided some good explanatory diagrams in his message this 
week, and suggested a delimiter approach to breaking the DN into a 
prefix that uniquely identifies a subject, vs. a suffix that is just 
for display purposes. This is an example of a much more powerful 
mechanism, that goes beyond the original problem and tries to provide 
a means of generally expressing what parts of a DN are critical for 
uniqueness, vs. what parts are just for display to a user. Peter 
Sylvester suggested the same sort of marker. I'm not comfortable with 
this approach because it represents a fundamental change to the 
semantics of a DN, and others are not happy with it since it 
introduces a new attribute, which could cause backward compatibility 
problems.

Stefan suggested a bit string approach to specifying which attributes 
contribute to the unique part of the DN.  This approach avoids the 
for a new attribute, but suffers from the fact that some of these 
attributes can be replicated in a DN, so that the bit string may not 
be able to express the exact attribute subset unless some constraints 
are imposed on the DN schema. Denis's refinement of this approach 
depends on an old RFC that recommends schema constraints for the DNs. 
I tried to do this sort of thing several years earlier in RFC 1422, 
and was suitably chastised then. I don't think it's any more viable 
now.

Bengt Ohlsson suggested another approach to the general problem, 
putting the "unique" DN in the Subject Alt Name extension, as a 
directoryName. This avoids the need for a new extension, the need to 
create a new attribute,  or the need to impose schema constraints. 
However, the example he provides does not exactly match the scenarios 
we have been describing; he said "if the serialNumber attribute is 
unique by itself, then the SubjectAltName entry will only contain the 
serialNumber."  This example would require that the serialNumber be 
globally unique, not just unique per country.  The QC examples we 
have discussed don't involve globally unique ID numbers, so the 
example probably needs to be modified a bit to represent the 
scenarios we have been discussing. This is a valid approach to the 
issue, so long as the SubjectAltNames are real DNs.

Antonio Lioy seconded this approach and gave examples, but here I am 
a bit confused. Antonio spoke of using a distinct OID for each new 
name he inserted; "Each subjectAltName is distinguished by a unique 
OID and hence each application can look for the one that it is able 
to deal with."   Is the OID for an attribute in a directoryName, or 
is it a new GeneralName name type?  The examples provided don;'t 
sounds like DNs: "we use it to insert our unique University ID but a 
second extension could be added for standard Italian national 
personal code, or for the case where the same individual belongs to 
two different organizations." If one creates new attribute types and 
uses them as stand-alone, single attribute DNs, this does not address 
the backward compatibility concerns raised earlier, and these names 
are probably not really DNs, e.g., without other attributes as a 
prefix, they are not likely to be suitable names in the DIT.

I'm comfortable with the approach Bengt proposed, assuming that the 
SubjectAltNames are real DNs, as I explained above. This seems to 
address the original problem, without introducing a new attribute, 
new extension, etc.
I would avoid constructs that put an arbitrary set of attributes into 
this extension, though, if calling the result a DN would be a 
misnomer. Also, I'm not a big fan of putting in multiple 
SubjectAltNames. Doing so causes added complexity in applying the 
NameConstraints extension and it imposes burdens on CAs to verify 
identity information from a wider range of name spaces.  However, for 
purposes of solving the problem that started this thread, I think we 
have a solution.

Finally, Anders, this does nothing to address your more recent desire 
to impose the concept of a naming domain on DNs.  Since DNs exist in 
the context of a DIT, which establishes naming domains via hierarchic 
refinement (the same way the DNS does), I suspect that what you are 
asking for here is not consistent with the use of a DN anyway.  Maybe 
we're back at the "have your cake and eat it too" stage for this 
issue.

Steve

--============_-1260603158==_ma============
Content-Type: text/enriched; charset="us-ascii"

Anders,

<excerpt>You are free to continue to outlaw DN interpretation support
schemes (should include the latest

suggestions by Stefan and David Kemp) in the same way as dnQualifier in
spite of the fact that

both belong to current practice and work just fine.

</excerpt>

<bigger>Irrespective of the technical issues we are discussing, there
seems to be some confusion about the purpose of the IETF standards
process, and of this WG's charter.

It is NOT the goal of this WG to produce standards primarily based on
current practice.  If that were the case, we would not have depricated
the use of the Common Name as a means of expressing an RFC 822 name or
a DNS name.  There is considerable common practice here, but its
inappropriate and thus 2459 strongly encourages use of the appropriate
name forms and discourages misuse of the DN name form in this fashion.
So, I think that we have established the flavor of what PKIX tries to
do in this regard.

The charter of PKIX stated that we were profiling X.509 standards for
use in the Internet, extending such standards as needed to meet
Internet needs.  Sometimes we diverge from X.509, when we think it is
absolutely necessary, but we usually work with the X.509 folks to 
achieve compatible solutions.  The proposed change to the definition of
serialNumber is such an example, and, in the recent past, the change to
the basicConstraints extension.  So, we do take issues at times with
what X.509 does, and we work to resolve such problems, but we do not do
so lightly.

The issue that triggered this expending debate was the observation that
an ID number assigned as part of a DN used in a QC might, in many
instances, uniquely identify the subject. Moreover, an RP would like to
take advantage of this feature to compare two QCs issued with differing
DNs, but by the same CA, to determine if the same entity was
represented by them, despite differences in the DN.  I can appreciate
the desire to be able to make such a comparison, but I also note that
this comparison approach clearly assumes knowledge outside of the DN
semantics.  

What we have here is a desire to have one's cake and eat it too :-). 
You want to make use of the DN syntax because of the ability of
existing software to parse DNs, but the semantics of what you want to
express is not really a DN. In other instances we have defined new
objects to represent other name types, but here, since name would make
use of the same attributes, it seems less critical to define a new
object under the GeneralName  structure. The challenge is to consider
way to resolve this issue, without breaking the existing semantics of
DNs and while minimizing the need to create new software. Fortunately,
i think we have a porposal that does that, as explained below.

Tom Gindin posed a good set of questions that are related to the issue
I described above, but also are somewhat independent. I think the
redefinition of serialNumber addresses the fundamental concern he
raised.  However, this redefinition, although it allows a unique,
national ID to be represented, does not change the semantics of a DN in
support of the comparison goal described above.  To know that a
serialNumber attribute has the property of uniquely identifying a
subjetc, all but itself, one has to communicate this in some fashion to
software operating for RPs.

Dave Kemp provided some good explanatory diagrams in his message this
week, and suggested a delimiter approach to breaking the DN into a
prefix that uniquely identifies a subject, vs. a suffix that is just
for display purposes. This is an example of a much more powerful
mechanism, that goes beyond the original problem and tries to provide a
means of generally expressing what parts of a DN are critical for
uniqueness, vs. what parts are just for display to a user. Peter
Sylvester suggested the same sort of marker. I'm not comfortable with
this approach because it represents a fundamental change to the
semantics of a DN, and others are not happy with it since it introduces
a new attribute, which could cause backward compatibility problems.

Stefan suggested a bit string approach to specifying which attributes
contribute to the unique part of the DN.  This approach avoids the for
a new attribute, but suffers from the fact that some of these
attributes can be replicated in a DN, so that the bit string may not be
able to express the exact attribute subset unless some constraints are
imposed on the DN schema. Denis's refinement of this approach depends
on an old RFC that recommends schema constraints for the DNs.  I tried
to do this sort of thing several years earlier in RFC 1422, and was
suitably chastised then. I don't think it's any more viable now.

Bengt Ohlsson suggested another approach to the general problem,
putting the "unique" DN in the Subject Alt Name extension, as a
directoryName. This avoids the need for a new extension, the need to
create a new attribute,  or the need to impose schema constraints.
However, the example he provides does not exactly match the scenarios
we have been describing; he said "</bigger>if the serialNumber
attribute is unique by itself, then the SubjectAltName entry will only
contain the serialNumber."  <bigger>This example would require that the
serialNumber be globally unique, not just unique per country.  The QC
examples we have discussed don't involve globally unique ID numbers, so
the example probably needs to be modified a bit to represent the
scenarios we have been discussing. This is a valid approach to the
issue, so long as the SubjectAltNames are real DNs.

Antonio Lioy seconded this approach and gave examples, but here I am a
bit confused. Antonio spoke of using a distinct OID for each new name
he inserted; "</bigger>Each subjectAltName is distinguished by a unique
OID and hence each application can look for the one that it is able to
deal with.<bigger>"   Is the OID for an attribute in a directoryName,
or is it a new GeneralName name type?  The examples provided don;'t
sounds like DNs: "</bigger>we use it to insert our unique University ID
but a second extension could be added for standard Italian national
personal code, or for the case where the same individual belongs to two
different organizations.<bigger>" If one creates new attribute types
and uses them as stand-alone, single attribute DNs, this does not
address the backward compatibility concerns raised earlier, and these
names are probably not really DNs, e.g., without other attributes as a
prefix, they are not likely to be suitable names in the DIT.  

I'm comfortable with the approach Bengt proposed, assuming that the
SubjectAltNames are real DNs, as I explained above. This seems to
address the original problem, without introducing a new attribute, new
extension, etc.

I would avoid constructs that put an arbitrary set of attributes into
this extension, though, if calling the result a DN would be a misnomer.
Also, I'm not a big fan of putting in multiple SubjectAltNames. Doing
so causes added complexity in applying the NameConstraints extension
and it imposes burdens on CAs to verify identity information from a
wider range of name spaces.  However, for purposes of solving the
problem that started this thread, I think we have a solution.

Finally, Anders, this does nothing to address your more recent desire
to impose the concept of a naming domain on DNs.  Since DNs exist in
the context of a DIT, which establishes naming domains via hierarchic
refinement (the same way the DNS does), I suspect that what you are
asking for here is not consistent with the use of a DN anyway.  Maybe
we're back at the "have your cake and eat it too" stage for this
issue.

Steve
</bigger>

--============_-1260603158==_ma============--

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: Cert Path Validation Bug in pkix-new-part1-00 
Date: Fri, 25 Feb 2000 17:07:57 -0500

All,

From: [email-masked]
To: "Hesse, Johan" <[email-masked]>
cc: [email-masked], [email-masked]
Date: Fri, 25 Feb 2000 16:48:10 -0500
Subject: Re: AW: German Law and OCSP

     There is also a set of technical rules associated with that
presidential decree at the link
http://www.aipa.it/attivita[2/protocollo[13/normprot[1/regole428.asp.
Please note that the link contains left square brackets in file names, not
parentheses.

          Tom Gindin

Date: Fri, 25 Feb 2000 11:27:06 -0700
From: "Tammy Green" <[email-masked]>
To: <[email-masked]>
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
[email-masked] 
Software Engineer
Novell, Inc.

>>> "Bob Jueneman" <[email-masked]> 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
[email-masked] 
Software Engineer
Novell, Inc.

Date: Fri, 25 Feb 2000 17:57:30 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Herfert <[email-masked]>
CC: [email-masked]
Subject: Re: German Law and OCSP

Michael,

Thank for attempting to answer to the question. However, the right
explanation is not contained in this E-mail where it is said: "user
certificates must remain valid if a CA looses the license", but in
the other E-mail sent to Hans Nilsson where it is said:

"The german law requires that user certificates must be valid, even
if the CA key has been corrupted."

This sentence does not appear in the extracts you provide below:

1) The first sentence of §13 (5) does not address the case of CA key
compromise.

2) The second sentence of §13 (5) orders invalidation of
certificates which is in contradiction with maintaining the validity
of certificates, even if the CA key has been corrupted.

3) The sentence of §8(3) talks about invalidation, not maintaining
the validity of the certificate.

The fact that by §13(5) user certificates must remain valid if a CA
looses the license, does not mean that the CA key is compromised. A
CA may loose its license without any key compromission.

The idea is nevertheless to consider the way to handle the case of
CA key compromission. 

The basic question is whether there is a need to modify RFC 2459 to
handle CA key compromission. If there is such a need, this cannot
interpreted from this text.

Denis

> Hello Denis and all,
> 
> Denis Pinkas wrote:
> > Besides the wording, the question was to understand the rational of
> > the model. The question is still pending ...
> 
> The standard X.509 model does not satisfy the requierements of the german
> law. So there was a need for a new model. The important paragraphs are:
> 
> §13(5): "The validity of the certificates issued by a certification
>          authority shall remain unaffected by the withdrawal or
>          revocation of a licence. The competent authority may order the
>          invalidation of certificates when facts warrant the assumption
>          that certificates have been forged or are not adequately
>          protected against forgery or when technical components
>          used for the signature keys reveal security flaws enabling
>          digital signatures to be forged or signed data to be
>          manipulated without detection."
> 
> §8(3):  "The competent authority shall invalidate certificates which it has
>          issued according to §4(5) when a certification authority
>          ceases operation or its licence is withdrawn or revoked."
> 
> Assume a CA looses its license, for example because it has lost its money.
> According to §8(3) the competent authority (= the german root CA)
> must revoke the certificate.
> 
> By §13(5) user certificates must remain valid if a CA looses the license.
> 
> So we have a revoked CA certificate and valid user certificates.
> This case can not be handled by the standard X.509 model.
> 
> ---
> 
> The SigG model is an easy and effective model.
> Assume a two level hierarchy:
>         root CA
>         CA
>         users
> 
> 1. Now Alice wants to verify 10000 digital signatures
>    with respect to the standard model.
>    She decides that she needs online verification of certificates.
>    For the first signature she must ask her online service three times:
>      to verify the user certificate
>      to verify the CA certificate
>      to verify the root certificate
>    So for 10000 verifications she needs 30000 requests.
> 
> 2. On the other side, Bob verifies the same amount of signatures
>    by the SigG model.
>    He first verifies the CA and the root CA certificates.
>    He can store the results and reuse them in the future.
>    So for 10000 verifications Bob needs 10002 requests.
> 
> ---
> 
> A standard X.509 directory service may be joined with the german signature law.
> Alice ask this service for the certificate of Bob.
> The service answers by sending Bob's certificate
> (if Bob has allowed this).
> The certificate is signed by the CA, like always,
> but it has no extra signature.
> The meaning of the answer is:
>   Alice, this is Bob's certificate. It may be valid
>   or not. If you want to know the exact status,
>   ask the validation service.
> 
> If we replace the words "validation service" by "OCSP"
> then this is exact the meaning we have in the standard model.
> 
> Greetings,
> Michael
> 
> ---
> 
> Michael Herfert
> GMD - German National Research Center for Information Technology
> Darmstadt
> Germany

From: Ambarish Malpani <[email-masked]>
To: [email-masked]
Subject: RE: German Law and OCSP
Date: Fri, 25 Feb 2000 07:31:50 -0800

Hi Michael,
    - The requirements you have specified could be met by using
standard OCSP and requiring the VA to send over the full cert
hash in the response.
    - If a CA cert signing key has been compromised, I would
treat everything issued by the CA as suspect - you would open
yourself up to too many attacks - it isn't worth it to try and
save the certificates that were legitimately issued.

Regards,
Ambarish

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

> -----Original Message-----
> From: Michael Herfert [mailto:[email-masked]]
> Sent: Friday, February 25, 2000 7:14 AM
> To: Denis Pinkas; [email-masked]
> Subject: Re: German Law and OCSP
> 
> 
> Hello Denis and all,
> 
> Denis Pinkas wrote:
> > Besides the wording, the question was to understand the rational of
> > the model. The question is still pending ...
> 
> The standard X.509 model does not satisfy the requierements 
> of the german 
> law. So there was a need for a new model. The important 
> paragraphs are:
> 
> 
> §13(5):	"The validity of the certificates issued by a 
> certification 
>          authority shall remain unaffected by the withdrawal or 
> 	 revocation of a licence. The competent authority may order the
>      	 invalidation of certificates when facts warrant the assumption 
> 	 that certificates have been forged or are not adequately 
> 	 protected against forgery or when technical components
>      	 used for the signature keys reveal security flaws enabling 
> 	 digital signatures to be forged or signed data to be 
> 	 manipulated without detection." 
> 
> §8(3):	"The competent authority shall invalidate 
> certificates which it has 
>   	 issued according to §4(5) when a certification authority 
>       	 ceases operation or its licence is withdrawn 
> or revoked."
> 
> 
> Assume a CA looses its license, for example because it has 
> lost its money.
> According to §8(3) the competent authority (= the german root CA) 
> must revoke the certificate. 
> 
> By §13(5) user certificates must remain valid if a CA looses 
> the license.
> 
> So we have a revoked CA certificate and valid user certificates.
> This case can not be handled by the standard X.509 model.
> 
> ---
> 
> The SigG model is an easy and effective model.
> Assume a two level hierarchy:  
> 	root CA
> 	CA
> 	users
> 
> 1. Now Alice wants to verify 10000 digital signatures 
>    with respect to the standard model.
>    She decides that she needs online verification of certificates.
>    For the first signature she must ask her online service 
> three times:
>      to verify the user certificate
>      to verify the CA certificate
>      to verify the root certificate
>    So for 10000 verifications she needs 30000 requests.
> 
> 2. On the other side, Bob verifies the same amount of signatures
>    by the SigG model.
>    He first verifies the CA and the root CA certificates.
>    He can store the results and reuse them in the future.
>    So for 10000 verifications Bob needs 10002 requests.
> 
> ---
> 
> A standard X.509 directory service may be joined with the 
> german signature law.
> Alice ask this service for the certificate of Bob.
> The service answers by sending Bob's certificate 
> (if Bob has allowed this).
> The certificate is signed by the CA, like always,
> but it has no extra signature.
> The meaning of the answer is: 
>   Alice, this is Bob's certificate. It may be valid
>   or not. If you want to know the exact status,
>   ask the validation service.
> 
> If we replace the words "validation service" by "OCSP" 
> then this is exact the meaning we have in the standard model.
> 
> Greetings,
> Michael
> 
> ---
> 
> Michael Herfert
> GMD - German National Research Center for Information Technology
> Darmstadt
> Germany
> 

Date: Fri, 25 Feb 2000 16:14:15 +0100
From: Michael Herfert <[email-masked]>
To: Denis Pinkas <[email-masked]>, [email-masked]
Subject: Re: German Law and OCSP

Hello Denis and all,

Denis Pinkas wrote:
> Besides the wording, the question was to understand the rational of
> the model. The question is still pending ...

The standard X.509 model does not satisfy the requierements of the german 
law. So there was a need for a new model. The important paragraphs are:

§13(5):	"The validity of the certificates issued by a certification 
         authority shall remain unaffected by the withdrawal or 
	 revocation of a licence. The competent authority may order the
     	 invalidation of certificates when facts warrant the assumption 
	 that certificates have been forged or are not adequately 
	 protected against forgery or when technical components
     	 used for the signature keys reveal security flaws enabling 
	 digital signatures to be forged or signed data to be 
	 manipulated without detection." 

§8(3):	"The competent authority shall invalidate certificates which it has 
  	 issued according to §4(5) when a certification authority 
      	 ceases operation or its licence is withdrawn or revoked."

Assume a CA looses its license, for example because it has lost its money.
According to §8(3) the competent authority (= the german root CA) 
must revoke the certificate. 

By §13(5) user certificates must remain valid if a CA looses the license.

So we have a revoked CA certificate and valid user certificates.
This case can not be handled by the standard X.509 model.

---

The SigG model is an easy and effective model.
Assume a two level hierarchy:  
	root CA
	CA
	users

1. Now Alice wants to verify 10000 digital signatures 
   with respect to the standard model.
   She decides that she needs online verification of certificates.
   For the first signature she must ask her online service three times:
     to verify the user certificate
     to verify the CA certificate
     to verify the root certificate
   So for 10000 verifications she needs 30000 requests.

2. On the other side, Bob verifies the same amount of signatures
   by the SigG model.
   He first verifies the CA and the root CA certificates.
   He can store the results and reuse them in the future.
   So for 10000 verifications Bob needs 10002 requests.

---

A standard X.509 directory service may be joined with the german signature law.
Alice ask this service for the certificate of Bob.
The service answers by sending Bob's certificate 
(if Bob has allowed this).
The certificate is signed by the CA, like always,
but it has no extra signature.
The meaning of the answer is: 
  Alice, this is Bob's certificate. It may be valid
  or not. If you want to know the exact status,
  ask the validation service.

If we replace the words "validation service" by "OCSP" 
then this is exact the meaning we have in the standard model.

Greetings,
Michael

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany

Date: Fri, 25 Feb 2000 16:10:56 +0100
From: Michael Herfert <[email-masked]>
To: Hans Nilsson <[email-masked]>
CC: "'Ambarish Malpani'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: German Law and OCSP

Hello,

Hans Nilsson wrote:
> (For non-German speakers: "Good" means that the certificate is issued by the
> CA, known in the Directory and not revoked)
> 
> This is quite a different interpretation of "good" from RFC 2560, where
> "good" not necessarily means that the certificate has been issued!!!

there are two important differences between standard OCSP and SigG OCSP:

1. The meaning of "good":
   I think Hans is right in this point.

2. The single request extension certHash:
   The german law requires that user certificates must 
   be valid, even if the CA key has been corrupted.
   The extensions certHash contains the hash value of the certificate 
   being asked. It is a MUST in every request. 
   Without this value the service would not work 
   according to the law because the identification of a certificate by 
   (issuerNameHash, issuerKeyHash, serialNumber)
   is only a valid reference if the CA cert signing key is okay.
   Assume Alice has the serial number 5.
   In a desaster case where the CA cert signing key has been broken,
   an attacker may generate a certificate for Bob which has the 
   serial number 5, too. 
   In the same matter he may generate many faked certificates 
   that share a serial number with a correct certificate.

Michael 

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany

Date: Fri, 25 Feb 2000 16:09:04 +0100
From: Michael Herfert <[email-masked]>
To: [email-masked]
Subject: Re: OCSP and German Law

Hallo,

Stefan Kelm wrote:
> If someone
> doesn't want your certificate to be validated (e.g., because you digitally
> signed an order to buy one million new shares of that interesting company
> and the attacker doesn't like that) he shuts down the directory server
> for a while.

Consider the X.509 standard model:
If the verifier receives a high value transaction 
he asks his standard OCSP service in order to 
be sure that the certificate ist not revoked.
This standard service may be attacked in the same
was as in the SigG case.
So there is no difference with respect to this attack.

Michael 

---

Michael Herfert
GMD - German National Research Center for Information Technology
Darmstadt
Germany

From: Fantou Patrick <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked], Tammy Green <[email-masked]>
Cc: Fantou Patrick <[email-masked]>
Subject: AW: What if the CRL distribution points for a CA change?
Date: Fri, 25 Feb 2000 15:07:48 +0100

Hi Bob,

Can you please tell me what you mean with "LDAP forms of CRL distribution
points" ?
Thanks
Patrick
--
----------------------------------------------------------------------------
Patrick Fantou			Tel : +49 89 722 53243	
Siemens AG			Fax: +49 89 722 53722
Trusted Networks and Applications
ICN ISA TNA 4
Otto-Hahn-Ring 6, D.81739-Munich, Germany
e-mail : [email-masked]
----------------------------------------------------------------------------
-

> -----Ursprüngliche Nachricht-----
> Von:	Bob Jueneman [SMTP:[email-masked]]
> Gesendet am:	Freitag, 25. Februar 2000 06:50
> An:	[email-masked]; [email-masked]; Tammy Green
> Betreff:	Re: What if the CRL distribution points for a CA change?
> 
> Serves me right for not paying adequate attention to the cc list.  I
> thought I was responding to an internal Novell discussion, and did not
> intend to post such a  flip response to this list, nor to necessarily
> suggest that only LDAP forms of CRL distribution points should be used.
> 
> In the more general context, I think Tammy's points are worth discussing.
> 
> Bob
> 
> >>> "Bob Jueneman" <[email-masked]> 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
> [email-masked] 
> Software Engineer
> Novell, Inc.
> 

From: "Hesse, Johan" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: OCSP and German Law
Date: Fri, 25 Feb 2000 12:38:54 +0100

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_01BF7F85.03A72F00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> -----Urspr=FCngliche Nachricht-----
> Von:	Stefan Kelm [SMTP:[email-masked]]
> Gesendet am:	Freitag, 25. Februar 2000 10:40
> An:	[email-masked]
> Betreff:	Re: OCSP and German Law
>=20
> Johan,
>=20
> > I agree to Stefan, I bet a box of beer that the "validity model" in =
the
> > German Law won't change.
>=20
> According to the (still internal) drafts of the new law it won't =
change at
> all.
>=20
> > The advantage is more or less of legal and/or organizational =
nature. If
> the
> > CA signs a certificate, the PSE (e.g. your smart card with your
> *private*
> > key) has to be delivered in a secure way to the owner.
> >
> > In technical terms the certificate is almost valid (but not in =
legal
> terms).
> > But the PSE hasn't handed out to the owner yet, - with all =
possibilities
> of
> > abuse (I know there are ways to handle it in another way). But if =
you
> wait
> > until the owner proofs that he received the PSE, to say the =
certificate
> is
> > valid you avoid this insecure time gap. The validation is =
manifested by
> > publishing the certificate.
> >
> > So I hope you see the rational of this validity model.
>=20
> I think this is pretty plausible. However, using this model the =
directory
> is much more burdened with security issues than usual. =
Denial-of-service
> attacks against the directory become much more crucial, IMHO. If =
someone
> doesn't want your certificate to be validated (e.g., because you =
digitally
> signed an order to buy one million new shares of that interesting =
company
> and the attacker doesn't like that) he shuts down the directory =
server
> for a while.
>=20
>=20
	[Hesse, Johan]  Yes, - that's the point. But I didn't say that the
model was the only one or rather the best.
	But the denial of service attacks seems to be independent from this
model (?).

	For contract partner it's of particular importance that they can
check the status of the certificates within some minutes (see your =
example
of the financial transaction). So the DIR has to be available at any =
time.
In practice it will be the weak point.=20

	Cheers, Johan

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : +49 (0)40/696599-12
> Fax   : +49 (0)40/696599-29
> mailto:[email-masked]
> **************************************
>=20
>=20

------_=_NextPart_001_01BF7F85.03A72F00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>AW: OCSP and German Law</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Urspr=FCngliche =
Nachricht-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Von:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">Stefan Kelm [SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Gesendet =
am:&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 FACE=3D"Arial">Freitag, =
25. Februar 2000 10:40</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">An:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">[email-masked]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Betreff:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: OCSP and German Law</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Johan,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I agree to Stefan, I bet a box of =
beer that the &quot;validity model&quot; in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; German Law won't change.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">According to the (still internal) =
drafts of the new law it won't change at all.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The advantage is more or less of =
legal and/or organizational nature. If the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; CA signs a certificate, the PSE =
(e.g. your smart card with your *private*</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; key) has to be delivered in a =
secure way to the owner.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; In technical terms the =
certificate is almost valid (but not in legal terms).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; But the PSE hasn't handed out to =
the owner yet, - with all possibilities of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; abuse (I know there are ways to =
handle it in another way). But if you wait</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; until the owner proofs that he =
received the PSE, to say the certificate is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; valid you avoid this insecure =
time gap. The validation is manifested by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; publishing the =
certificate.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; So I hope you see the rational =
of this validity model.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think this is pretty plausible. =
However, using this model the directory</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is much more burdened with security =
issues than usual. Denial-of-service</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">attacks against the directory become =
much more crucial, IMHO. If someone</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">doesn't want your certificate to be =
validated (e.g., because you digitally</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signed an order to buy one million =
new shares of that interesting company</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and the attacker doesn't like that) =
he shuts down the directory server</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for a while.</FONT>
</P>
<BR>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Yes, - that's the point. But I didn't say that the =
model was the only one or rather the best.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But the denial of =
service attacks seems to be independent from this model (?).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">For contract partner =
it's of particular importance that they can check the status of the =
certificates within some minutes (see your example of the financial =
transaction). So the DIR has to be available at any time. In practice =
it will be the weak point.</FONT> </P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers, =
Johan</FONT></I></B>
</P>
</UL>
<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7F85.03A72F00--

From: "Hesse, Johan" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: German Law and OCSP
Date: Fri, 25 Feb 2000 12:23:36 +0100

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_01BF7F82.F8A090B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> -----Urspr=FCngliche Nachricht-----
> Von:	Paul Halliden [SMTP:[email-masked]]
> Gesendet am:	Donnerstag, 24. Februar 2000 17:53
> An:	'Hesse, Johan'; [email-masked]; [email-masked];
> [email-masked]
> Cc:	[email-masked]
> Betreff:	RE: German Law and OCSP
>=20
> > It seems that there are a lot of confusions regarding some terms=20
> > in the German Law. =20
> Agreed ;)
>=20
> [snip]
>=20
> > I think the confusion springs from legal terms. In the above=20
> > mentioned example the technical term of *valid* for a certificate=20
> > would be the moment of the signing with the signing key.=20
> Technically a certificate is valid from the date and time contained =
in the
> ASN.1 element "notBefore" in the "Validity" sequence of the X.509
> structure.
> This may or may not be the time of signing by the CA.  Indeed, it may =
be
> delayed with respect to time of signing to cope with the scenario you
> describe in your later mail.  This is the same as the process known =
as
> "Thro
> dating" used by credit card companies to protect against the risks =
you
> mention.
>=20
	[Hesse, Johan]  O.k. But the element "notBefore" doesn't help in
this scenario. If you don't know how long it exactly takes that the PSE =
is
handed out to the intended end user. May be 2 minutes and the user =
wants to
sign immediately (personal handing out), or 2 weeks (the user is absent =
and
sends the acknowledgement later).

> > The legal term assumes the publishing of the certificate.
> >
> > Another misunderstanding seems to be the role of the CRL in German =
Law.=20
> > Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> > to prove that a cert was not valid at a certain date is to provide
> > a CRL (or a CSL!!!) that includes it." The German Law requires
> > only the *checkability* of the status of a certificate for anybody=20
> > to any time (=A74 SigG).=20
> This is =A75(1) in my (English) copy dated 1 August 1997.  Is there a =
later
> version?  More importantly, it was explained to me that the German =
model
> needed to know if a certificate was valid at the time that the
> corresponding
> signature key was originally used and not at the time the request for
> validation is performed.  This is because one might be checking a =
legal
> document that is tens of years old.  Is that what you mean by "to any
> time"?
>=20
	[Hesse, Johan]  You are right, =A75. I have to learn the Law by heart
again ;-)
> > The interoperability schemes (SigI A5) propose OCSP.=20
> As I understand it, OCSP is designed to tell you status now not =
status at
> some previous date.  If so, is this another issue with German Law and
> OCSP?
>=20
> > The status *suspension* isn't allowed according to the German Law,=20
> > in comparison with Italian law which requires a CRL (Art. 29 par. =
3)
> > and the possibility of suspension (Art. 33).
> Do you have a reasonable English translation of the Italian law - or =
a
> link
> to a translation?
>=20
>=20
	[Hesse, Johan]  Sorry, I have the law only in italian. The details
concerning suspension and CRL as mentioned above can be find in the =
"Decreto
del Presidente del Consiglio dei Ministri, 8 febbraio 1999" under
http://www.aipa.it/servizi[3/normativa[4/leggi[1/regfin.asp  .     =20

	Ciao, Johan

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : +49 (0)40/696599-12
> Fax   : +49 (0)40/696599-29
> mailto:[email-masked]
> **************************************
>=20
>=20
>=20
>=20

------_=_NextPart_001_01BF7F82.F8A090B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>AW: German Law and OCSP</TITLE>
</HEAD>
<BODY>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Urspr=FCngliche =
Nachricht-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Von:&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT SIZE=3D1 FACE=3D"Arial">Paul Halliden =
[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Gesendet =
am:&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Donnerstag, 24. Februar 2000 17:53</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">An:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">'Hesse, Johan'; [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">[email-masked]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Betreff:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: German Law and OCSP</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; It seems that there are a lot of =
confusions regarding some terms </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in the German Law.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Agreed ;)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I think the confusion springs =
from legal terms. In the above </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; mentioned example the technical =
term of *valid* for a certificate </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; would be the moment of the =
signing with the signing key. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Technically a certificate is valid =
from the date and time contained in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ASN.1 element &quot;notBefore&quot; =
in the &quot;Validity&quot; sequence of the X.509 structure.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This may or may not be the time of =
signing by the CA.&nbsp; Indeed, it may be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">delayed with respect to time of =
signing to cope with the scenario you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">describe in your later mail.&nbsp; =
This is the same as the process known as &quot;Thro</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dating&quot; used by credit card =
companies to protect against the risks you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mention.</FONT>
</P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> O.k. But the element &quot;notBefore&quot; doesn't help =
in this scenario. If you don't know how long it exactly takes that the =
PSE is handed out to the intended end user. May be 2 minutes and the =
user wants to sign immediately (personal handing out), or 2 weeks (the =
user is absent and sends the acknowledgement later).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The legal term assumes the =
publishing of the certificate.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Another misunderstanding seems =
to be the role of the CRL in German Law. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Antonio Lioy wrote (28.01.2000) =
&quot;... the only legally binding way</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to prove that a cert was not =
valid at a certain date is to provide</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a CRL (or a CSL!!!) that =
includes it.&quot; The German Law requires</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; only the *checkability* of the =
status of a certificate for anybody </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to any time (=A74 SigG). </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This is =A75(1) in my (English) copy =
dated 1 August 1997.&nbsp; Is there a later</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">version?&nbsp; More importantly, it =
was explained to me that the German model</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">needed to know if a certificate was =
valid at the time that the corresponding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signature key was originally used and =
not at the time the request for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">validation is performed.&nbsp; This =
is because one might be checking a legal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">document that is tens of years =
old.&nbsp; Is that what you mean by &quot;to any time&quot;?</FONT>
</P>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> You are right, =A75. I have to learn the Law by heart =
again ;-)</FONT><B></B><B><I></I></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The interoperability schemes =
(SigI A5) propose OCSP. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As I understand it, OCSP is designed =
to tell you status now not status at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some previous date.&nbsp; If so, is =
this another issue with German Law and OCSP?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The status *suspension* isn't =
allowed according to the German Law, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in comparison with Italian law =
which requires a CRL (Art. 29 par. 3)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and the possibility of =
suspension (Art. 33).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Do you have a reasonable English =
translation of the Italian law - or a link</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to a translation?</FONT>
</P>
<BR>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">[Hesse, =
Johan]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"> Sorry, I have the law only in italian. The details =
concerning suspension and CRL as mentioned above can be find in the =
&quot;Decreto del Presidente del Consiglio dei Ministri, 8 febbraio =
1999&quot; under<U> <A HREF=3D"http://www.aipa.it/servizi" =
TARGET=3D"_blank">http://www.aipa.it/servizi</A>[3/normativa[4/leggi[1/r=
egfin.asp</U></FONT><U></U><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT><B></B><B><I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"> .</FONT></I><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"></FONT></B>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"></FONT><B></B><B><I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"></FONT></I></B><I></I>&nbsp;<FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"></FONT><B></B><B><I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"></FONT></I></B><I></I>&nbsp;<FONT SIZE=3D2 =
FACE=3D"Arial"> </FONT></P>
<BR>
<BR>

<P><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Ciao, =
Johan</FONT></I></B>
</P>
<BR>
</UL>
<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7F82.F8A090B0--

Date: Fri, 25 Feb 2000 10:40:29 +0100 (MET)
From: Stefan Kelm <[email-masked]>
To: [email-masked]
Subject: Re: OCSP and German Law
Reply-To: [email-masked]

Johan,

> I agree to Stefan, I bet a box of beer that the "validity model" in the
> German Law won't change.

According to the (still internal) drafts of the new law it won't change at all.

> The advantage is more or less of legal and/or organizational nature. If the
> CA signs a certificate, the PSE (e.g. your smart card with your *private*
> key) has to be delivered in a secure way to the owner.
>
> In technical terms the certificate is almost valid (but not in legal terms).
> But the PSE hasn't handed out to the owner yet, - with all possibilities of
> abuse (I know there are ways to handle it in another way). But if you wait
> until the owner proofs that he received the PSE, to say the certificate is
> valid you avoid this insecure time gap. The validation is manifested by
> publishing the certificate.
>
> So I hope you see the rational of this validity model.

I think this is pretty plausible. However, using this model the directory
is much more burdened with security issues than usual. Denial-of-service
attacks against the directory become much more crucial, IMHO. If someone
doesn't want your certificate to be validated (e.g., because you digitally
signed an order to buy one million new shares of that interesting company
and the attacker doesn't like that) he shuts down the directory server
for a while.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email-masked]" or via key server
DFN-PCA                                                      <[email-masked]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Subject: How are Naming Domains identified?
Date: Fri, 25 Feb 2000 09:48:41 -0000

Hi,
I would like to get some feedback on how naming domains are identified. 
Let's say that a DN is "CN=John Doe; SN=1234".   IMO that DN  (hopefully) expresses
an unmistakable identity witin a certain naming domain but nothing prevent a CA supporting
another naming domain to use the same DN for the same or another entity.

Background: Extract from a rather heated discussion regarding serialNumbers etc:

>>Anders wrote:

>>What is missing from the current suggestion is a Naming Domain definition.
>>I can just find two variants: Either the naming domain is marked as internal/CA
>>and does not have to be known outside, or the CA issues certificates to
>>an external naming domain like "registered Citizen of XYZ". The latter should
>>require an officially registered value of some kind to be interoperable among
>>competing CAs,

>Steve wrote:

>I think that your suggestion for a name domain definition is further evidence that the 
>identifiers that you are referring to are not really DNs!

Anders

From: Simon Tardell <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, [email-masked]
Subject: OCSP, historical answers
Date: Fri, 25 Feb 2000 09:47:03 +0100

Ambarish,

> Hi Paul,
>     Just one correction - OCSP can tell you of the historical
> status of a cert - there is an ArchiveCutoff mechanism. If your
> cert expired after ArchiveCutoff, then the status is as indicated
> in the response.

Yes, but what about a certificate that was put on-hold for a certain period
but then made valid again? There are of course ways to solve this using
timestamping, but it seems like an omission that neither OCSP nor CRLs have
a mechanism for giving a full account of the revocation history of a
certificate. 

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

Date: Thu, 24 Feb 2000 22:50:02 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Tammy Green" <[email-masked]>
Subject: Re: What if the CRL distribution points for a CA change?

Serves me right for not paying adequate attention to the cc list.  I thought I was responding to an internal Novell discussion, and did not intend to post such a  flip response to this list, nor to necessarily suggest that only LDAP forms of CRL distribution points should be used.

In the more general context, I think Tammy's points are worth discussing.

Bob

>>> "Bob Jueneman" <[email-masked]> 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
[email-masked] 
Software Engineer
Novell, Inc.

Date: Thu, 24 Feb 2000 21:55:58 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, "Tammy Green" <[email-masked]>
Subject: Re: What if the CRL distribution points for a CA change?

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
[email-masked] 
Software Engineer
Novell, Inc.

From: Ambarish Malpani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 19:52:59 -0800

Hi Alistair,
    Didn't you want to scrap OCSP entirely, anyway? :-)

How a VA gets and keeps access to its revocation data doesn't
need to involve access to the CAs repository. It could keep the
data locally/in memory.

Yes, I agree, you could return tryLater, the main thing I would
question is the value of making that a requirement on the
VA.

Regards,
Ambarish

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

> -----Original Message-----
> From: Grant, Alistair [mailto:[email-masked]]
> Sent: Thursday, February 24, 2000 3:54 PM
> To: Ambarish Malpani; [email-masked]'
> Subject: RE: German Law and OCSP
> 
> 
> Ambarish Malpani wrote:
> > II. The "publicly available" clause needs to be carefully
> > interpreted. I don't think it makes sense to force the VA
> > to try and retrieve the certificate in question from a
> > directory, because you *will* hit the situation where a
> > certificate was, in fact correctly issued, but because of
> > some transient network/machine problem, the VA can't get to
> > the repository for an instant in time. In that case, should
> > the VA return a status of bad/revoked/unknown/good? Which of
> > the responses is "correct"?
> 
> If we take this reasoning one step further, the responder 
> can't get the CRL
> because of some transient network/machine problem, what 
> should be done?
> Taking this to the (ridiculous) extreme, does that mean we 
> shouldn't force
> the responder to try and retrieve the CRL?
> 
> I think the common answer will be that the responder returns 
> unknown or
> tryLater until the CRL becomes available.
> 
> I don't believe that this particular argument holds against 
> requiring the
> responder to retrieve the certificate as part of the status check.
> 
> 
> Cheers,
> 
> 
> Alistair Grant
> Project Manager - Development
> Computer Associates, OpenDirectory Lab
> Melbourne, Victoria, Australia
> Phone:	+61 3 9727 8912
> Mobile:	+61 408 565 080
> Fax:	+61 3 9727 3491
> E-Mail:	[email-masked]
> 

Date: Thu, 24 Feb 2000 20:58:37 -0700
From: "Tammy Green" <[email-masked]>
To: <[email-masked]>
Cc: "Bob Jueneman" <[email-masked]>
Subject: What if the CRL distribution points for a CA change?

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
[email-masked] 
Software Engineer
Novell, Inc.

From: Ingmar Camphausen <[email-masked]>
Date: Fri, 25 Feb 2000 02:56:46 +0100
To: Ambarish Malpani <[email-masked]>
Subject: Re: German Law and OCSP
cc: [email-masked]
Reply-To: [email-masked]
Organization: Individual Network Berlin
Priority: normal

Ambarish,

> P.S. I, too, would appreciate pointers to English versions of both the
> German and Italian Digital Signature laws.
[...]
> >> Another misunderstanding seems to be the role of the CRL in German Law.
[...]
> > This is _5(1) in my (English) copy dated 1 August 1997.  Is there a
> > later version?
[...]
> > Do you have a reasonable English translation of the Italian law - or a
> > link to a translation?

The German wording of the Signaturgesetz ("German Digital Signature Act"
-- SigG) as passed by the German Bundestag (Parliament) on 13 June 1997
is online in HTML and PDF format at

	http://www.iid.de/rahmen/iukdgbt.html#a3

The English version (or translation?) of the German SigG, dated
"August 1 1997", is at

	http://www.iid.de/rahmen/iukdgebt.html#a3

As this is part of the online presence "Initiative Information Society
Germany" by the German Federal Government (Federal Ministry for Education
and Research), the German version of the SigG at the URL above should be
the exact wording of the Act.

The Act has not been changed or amended since it became effective.
(It is under review now, as Stefan Kelm mentioned earlier, and will be
modified and/or amended in some points to reflect the changes required
by the European Directive on electronic signatures "Council of 13 December
1999 on a Community framework for electronic signatures" -- online at
http://europa.eu.int/eur-lex/en/dat/2000/l_013/l_01320000119en00120020.pdf)

At http://www.iid.de/iukdg/sigve.html you can find an English version of
the German "Signaturverordnung" (Digital Signature Ordinance, SigV) that
concretizes some of the technical details intentionally omitted from the
SigG itself in order to make the SigG more "generic".

These -- and other -- documents related to digital signature legislation
in Germany and on the European level are also available from our project
FTP server at

	ftp://ftp.pca.dfn.de/pub/pca/docs/SigG/
	ftp://ftp.pca.dfn.de/pub/pca/docs/SigG/Europe/

		.	.	.

Regarding an English version of the _Italian_ Digital Signature
legislation, I can only point you to the section covering Italy in
Simone van der Hof's "Digital Signature Law Survey", online at

	http://cwis.kub.nl/~frw/people/hof/DS-lawsu.htm

It provides a nice (English) overview of how the Italian Digital
Signature legislation took place, as well as links to two English
texts about its unfolding.

Please note that some of the hyperlinks in that section have slightly
changed! The "Presidential Decree No. 513 of 10 November 1997" can be
found at

	http://www.aipa.it/english[4/law[3/law5997.asp

now, and the "Regulations establishing criteria and means for implementing
Section 15(2) of Law No. 59 of 15 March 1997 concerning the creation,
storage and transmission of documents by means of computer-based or
telematic systems" have moved to

	http://www.aipa.it/english[4/law[3/pdecree51397.asp

Hope this helps,

    Ingmar

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

From: "Ariel Silverstone" <[email-masked]>
To: <[email-masked]>
Subject: Unsub
Date: Thu, 24 Feb 2000 19:38:15 -0500
Importance: Normal

How may I Unsubscribe?

From: "Grant, Alistair" <[email-masked]>
To: Ambarish Malpani <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Fri, 25 Feb 2000 10:53:58 +1100

Ambarish Malpani wrote:
> II. The "publicly available" clause needs to be carefully
> interpreted. I don't think it makes sense to force the VA
> to try and retrieve the certificate in question from a
> directory, because you *will* hit the situation where a
> certificate was, in fact correctly issued, but because of
> some transient network/machine problem, the VA can't get to
> the repository for an instant in time. In that case, should
> the VA return a status of bad/revoked/unknown/good? Which of
> the responses is "correct"?

If we take this reasoning one step further, the responder can't get the CRL
because of some transient network/machine problem, what should be done?
Taking this to the (ridiculous) extreme, does that mean we shouldn't force
the responder to try and retrieve the CRL?

I think the common answer will be that the responder returns unknown or
tryLater until the CRL becomes available.

I don't believe that this particular argument holds against requiring the
responder to retrieve the certificate as part of the status check.

Cheers,

Alistair Grant
Project Manager - Development
Computer Associates, OpenDirectory Lab
Melbourne, Victoria, Australia
Phone:	+61 3 9727 8912
Mobile:	+61 408 565 080
Fax:	+61 3 9727 3491
E-Mail:	[email-masked]

Date: Thu, 24 Feb 2000 15:32:46 -0800
From: [email-masked]
To: [email-masked]
Subject: You are unsubscribed!

You have been unsubscribed from the First e-Commerce Corp Mailing List and if you ever
wish to re-subscibe just do so at our website.

Albert

Date: Thu, 24 Feb 2000 15:28:30 -0800
From: [email-masked]
To: [email-masked]
Subject: Legal Web Site

Still don't have an Interactive WEB Site? Have Directory Listing or a Web Page?

Almost everyone has joined in on the Internet revolution, including you, but what is in store for the future of the World Wide Web?  Traditional advertising will soon be completely swept away by the more powerful, more effective, more cost-conscious Internet.  

First E-Commerce Corporation specializes in designing interactive web sites for the legal community. Whether you already have a web page or simply advertise on the 'net, you are probably not seeing the results you'd like.   Most legal pages contain generic information and are difficult to locate. The key to the success of a web site is the amount of traffic that it brings. With our experienced web site developers and graphic designers, we can help you in creating greater visibility, expanding your client base, as well as provide a means for increasing services to existing clients. 

The sites that we design are not simply informative, but interactive as well.  Visiting your site should be something that the visitor enjoys experiencing again and again, a reference tool for both you and your clients.  Our sites send the message that your Firm is innovative and can use the most up to date technology to tackle their legal issues.  We hold the winning formula that will prove you are one step ahead and can offer the quickest, easiest, most cost-effective 
services to your clients.  

Our web site package will enable your clients access to forms and documents that can be downloaded from your site 24 hours a day.  You will be able to automatically bill clients for these additional services, while sending the message that your assistance is always available.  This will increase your billable hours without increasing the man-hours to do it. The Internet revolution has carried over to the courts as well, and our web sites enable you and your clients to file legal documents electronically.   Our database-enabled site is the first of it's kind, and allows easy access to legal forms and thousands of legal documents for both attorneys and clients.  

The First e-Commerce Corporation package is revolutionizing the way law firms conduct their daily communications with clients.  Come join the revolution and let us develop a site for your Firm that makes you stand out from the crowd.

Contact:		Lonnie Brookins
Tel:			408-727-3883 x101
Fax:			408-727-3882
E-Mail			[email-masked]

www.firstecc.com

   <BR><BR>
---------------------------------------------------------------------<BR>
We hope you have found this information useful. If you have any
suggestions or topics you would like to read more about, please let us know. If you would like to
unsubscribe, see the instructions below. Thank you and have a great day
and best wishes in
your online business!
 
REMOVAL INSTRUCTIONS:
Click on the link below to be removed from the 
First e-Commerce Corp Mailing List.<BR><BR>

<A HREF="http://www.firstecc.com/cgi-bin/mailmachine.cgi?[email-masked]">http://www.firstecc.com/cgi-bin/mailmachine.cgi?[email-masked]</A><BR>

This message is sent in compliance of the new email bill
section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618,
further transmissions to you by the sender of this email may be
stopped at no cost to you.This message is not intended for
residents in the State of WA, CA & VA Screening of addresses
has been done to the best of our technical ability.If you are a 
Washington, Virginia, or California resident please remove
yourself.

---------------------------------------------------------------------

From: Ambarish Malpani <[email-masked]>
To: [email-masked]
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 15:02:48 -0800

Hi Paul,
    Just one correction - OCSP can tell you of the historical
status of a cert - there is an ArchiveCutoff mechanism. If your
cert expired after ArchiveCutoff, then the status is as indicated
in the response.

Regards,
Ambarish

P.S. I, too, would appreciate pointers to English versions of both
the German and Italian Digital Signature laws.

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

> -----Original Message-----
> From: Paul Halliden [mailto:[email-masked]]
> Sent: Thursday, February 24, 2000 8:53 AM
> To: 'Hesse, Johan'; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: German Law and OCSP
> 
> 
> > It seems that there are a lot of confusions regarding some terms 
> > in the German Law.  
> Agreed ;)
> 
> [snip]
> 
> > I think the confusion springs from legal terms. In the above 
> > mentioned example the technical term of *valid* for a certificate 
> > would be the moment of the signing with the signing key. 
> Technically a certificate is valid from the date and time 
> contained in the
> ASN.1 element "notBefore" in the "Validity" sequence of the 
> X.509 structure.
> This may or may not be the time of signing by the CA.  
> Indeed, it may be
> delayed with respect to time of signing to cope with the scenario you
> describe in your later mail.  This is the same as the process 
> known as "Thro
> dating" used by credit card companies to protect against the risks you
> mention.
> 
> > The legal term assumes the publishing of the certificate.
> >
> > Another misunderstanding seems to be the role of the CRL in 
> German Law. 
> > Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> > to prove that a cert was not valid at a certain date is to provide
> > a CRL (or a CSL!!!) that includes it." The German Law requires
> > only the *checkability* of the status of a certificate for anybody 
> > to any time (§4 SigG). 
> This is §5(1) in my (English) copy dated 1 August 1997.  Is 
> there a later
> version?  More importantly, it was explained to me that the 
> German model
> needed to know if a certificate was valid at the time that 
> the corresponding
> signature key was originally used and not at the time the request for
> validation is performed.  This is because one might be 
> checking a legal
> document that is tens of years old.  Is that what you mean by 
> "to any time"?
> 
> > The interoperability schemes (SigI A5) propose OCSP. 
> As I understand it, OCSP is designed to tell you status now 
> not status at
> some previous date.  If so, is this another issue with German 
> Law and OCSP?
> 
> > The status *suspension* isn't allowed according to the German Law, 
> > in comparison with Italian law which requires a CRL (Art. 29 par. 3)
> > and the possibility of suspension (Art. 33).
> Do you have a reasonable English translation of the Italian 
> law - or a link
> to a translation?
> 

From: Paul Halliden <[email-masked]>
To: "'Hesse, Johan'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 16:52:50 -0000

> It seems that there are a lot of confusions regarding some terms 
> in the German Law.  
Agreed ;)

[snip]

> I think the confusion springs from legal terms. In the above 
> mentioned example the technical term of *valid* for a certificate 
> would be the moment of the signing with the signing key. 
Technically a certificate is valid from the date and time contained in the
ASN.1 element "notBefore" in the "Validity" sequence of the X.509 structure.
This may or may not be the time of signing by the CA.  Indeed, it may be
delayed with respect to time of signing to cope with the scenario you
describe in your later mail.  This is the same as the process known as "Thro
dating" used by credit card companies to protect against the risks you
mention.

> The legal term assumes the publishing of the certificate.
>
> Another misunderstanding seems to be the role of the CRL in German Law. 
> Antonio Lioy wrote (28.01.2000) "... the only legally binding way
> to prove that a cert was not valid at a certain date is to provide
> a CRL (or a CSL!!!) that includes it." The German Law requires
> only the *checkability* of the status of a certificate for anybody 
> to any time (§4 SigG). 
This is §5(1) in my (English) copy dated 1 August 1997.  Is there a later
version?  More importantly, it was explained to me that the German model
needed to know if a certificate was valid at the time that the corresponding
signature key was originally used and not at the time the request for
validation is performed.  This is because one might be checking a legal
document that is tens of years old.  Is that what you mean by "to any time"?

> The interoperability schemes (SigI A5) propose OCSP. 
As I understand it, OCSP is designed to tell you status now not status at
some previous date.  If so, is this another issue with German Law and OCSP?

> The status *suspension* isn't allowed according to the German Law, 
> in comparison with Italian law which requires a CRL (Art. 29 par. 3)
> and the possibility of suspension (Art. 33).
Do you have a reasonable English translation of the Italian law - or a link
to a translation?

From: Anders Rundgren <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 17:34:32 +0100

Steve,

<snip>

>>PS Steve, do you prefer that a solution according to my and Denis lines are
>>taken to PKI-FORUM rather than developed here?  I don't care where as
>>long as it gets done.  DS

>Is this a trick question?  Is it really an offer for you to move your 
>campaign for changes to ITU and IETF standards to an industry 
>consortium? How can I say no?

OK, I will not continue to push Plug'nPlay Certificates in IETF.
A great victory for purity!  "Consensus" rules!

You are free to continue to outlaw DN interpretation support schemes (should include the latest
suggestions by Stefan and David Kemp) in the same way as dnQualifier in spite of the fact that
both belong to current practice and work just fine.

And we will get International standards that contain phrases like "certificates must be compared with care".

Looks like a good time to invest in a PKI-consulting business.  :-)

Anders

From: Simon Tardell <[email-masked]>
To: "'Hesse, Johan'" <[email-masked]>, [email-masked]
Subject: RE: OCSP and German Law
Date: Thu, 24 Feb 2000 17:04:40 +0100

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

My comments below.

Hello! 

I agree to Stefan, I bet a box of beer that the "validity model" in the
German Law won't change. 

We accompanied TrustCenter which are conform to German Law and we saw that
this validity model has an advantage (maybe this is the rational of the
model). Since everyone seems to be unhappy with this validity model lets
mention the advantage to the honour of the good old law.

But please don't flame me, because I'm sure that there are other (better?)
possibilities. 

The advantage is more or less of legal and/or organizational nature. If the
CA signs a certificate, the PSE (e.g. your smart card with your *private*
key) has to be delivered in a secure way to the owner. 

In technical terms the certificate is almost valid (but not in legal terms).
But the PSE hasn't handed out to the owner yet, - with all possibilities of
abuse (I know there are ways to handle it in another way). But if you wait
until the owner proofs that he received the PSE, to say the certificate is
valid you avoid this insecure time gap. The validation is manifested by
publishing the certificate.

So I hope you see the rational of this validity model. 

I will not challenge your bet, but: This is not a good reason to mandate
that a validation authority must know if a certificate was ever issued. To
make sure that the certificate is not valid between the point in time where
it is issued and where the corresponding token is confirmed received by the
intended end-user you simply put it on-hold (revoke it with reason code
on-hold) until such confirmation is received. This is in my mind a rather
good way of using "suspension" (as compared to some of the more construed
scenarios we've been hearing). It was brought up that the German law does
not allow suspension. This is almost true -- but a certificate that has been
issued but not yet entered into the directory (SigG) is in fact suspended,
so for this exact purpose it seems ok. 

I think the point made by earlier by Andreas makes a lot of sense:

Another point is that the compromise of a CA key may be a very seldom event
but the potential cost, even with a desaster plan in place (anyone heard
about one from any CA?) it may be desirable to have simple technical
fallback position.

If the CA keys are compromised it can be prohibitingly expensive to replace
all certificates, especially since smart cards are mostly off-line. If there
is an independent notary service (which the directory (SigG) essentially is)
that can vouch for that a certificate was (or was not) issued before the
compromise of the CA keys, the tokens can be continued to be used. And, I
guess, there can be any number of "backup" directory (SigG) services,
improving reliability.

Simon.

Simon Tardell, Software Architect, iD2 Technologies 
[email-masked],  <http://www.id2tech.com/>
http://www.iD2tech.com/ 
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912 
European IT-prize grand winners 1998 --  <http://www.it-prize.org/>
http://www.it-prize.org 
AU-System Group Swedish IT-company of the year 1999 

------_=_NextPart_001_01BF7EE0.C4E602F0
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">
<TITLE>Re: OCSP and German Law</TITLE>

<META content="MSHTML 5.00.2919.3800" name=GENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>My 
comments below.</SPAN></FONT></P>
<P><EM><FONT face=Arial size=2>Hello!</FONT> </EM></P>
<P><EM><FONT face=Arial size=2>I agree to Stefan, I bet a box of beer that the 
"validity model" in the German Law won't change.</FONT> </EM></P>
<P><EM><FONT face=Arial size=2>We accompanied TrustCenter which are conform to 
German Law and we saw that this validity model has an advantage (maybe this is 
the rational of the model). Since everyone seems to be unhappy with this 
validity model lets mention the advantage to the honour of the good old 
law.</FONT></EM></P>
<P><EM><FONT face=Arial size=2>But please don't flame me, because I'm sure that 
there are other (better?) possibilities. </FONT></EM></P>
<P><EM><FONT face=Arial size=2>The advantage is more or less of legal and/or 
organizational nature. If the CA signs a certificate, the PSE (e.g. your smart 
card with your *private* key) has to be delivered in a secure way to the owner. 
</FONT></EM></P>
<P><EM><FONT face=Arial size=2>In technical terms the certificate is almost 
valid (but not in legal terms). But the PSE hasn't handed out to the owner yet, 
- with all possibilities of abuse (I know there are ways to handle it in another 
way). But if you wait until the owner proofs that he received the PSE, to say 
the certificate is valid you avoid this insecure time gap. The validation is 
manifested by publishing the certificate.</FONT></EM></P>
<P><EM><FONT face=Arial size=2>So I hope you see the rational of this validity 
model.</FONT> </EM></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>I will 
not challenge your bet, but: This is not a good reason to mandate that a 
validation authority must&nbsp;know&nbsp;if a certificate was ever issued. To 
make sure that the&nbsp;certificate is not valid between the point in time where 
it is issued and where&nbsp;the corresponding token is&nbsp;confirmed received 
by the intended end-user you simply put it on-hold (revoke it with reason code 
on-hold) until such confirmation is received. This is in my mind a rather good 
way of using "suspension" (as compared to some of the more construed scenarios 
we've been hearing). It was brought up that the German law does not allow 
suspension. This is almost true -- but a certificate that has been issued but 
not yet entered into the directory (SigG) is in fact suspended, so for this 
exact purpose it seems ok. </SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>I think 
the point made by earlier by Andreas makes a lot of 
sense:</SPAN></FONT></P><SPAN class=865014115-24022000>
<P><FONT size=2><EM><FONT face=Arial>Another point is that the compromise of a 
CA key may be a very seldom<SPAN class=865014115-24022000> </SPAN>event but the 
potential cost, even with a desaster plan in place (anyone<SPAN 
class=865014115-24022000> </SPAN>heard about one from any CA?) it may be 
desirable to have simple</FONT><FONT face=Arial><SPAN class=865014115-24022000> 
</SPAN>technical fallback position.</FONT></EM></FONT></P></SPAN>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=865014115-24022000>If the 
CA keys are compromised it can be prohibitingly expensive to replace all 
certificates, especially since smart cards are mostly off-line. If there is an 
independent notary service (which the directory (SigG) essentially is) that can 
vouch for that a certificate was (or was not) issued before the compromise of 
the CA keys, the tokens can be continued to be used. And, I guess, there can be 
any number of "backup" directory (SigG) services, improving 
reliability.</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN 
class=865014115-24022000>Simon.</SPAN></FONT></P>
<P><FONT size=2><FONT face=Arial>Simon Tardell, Software Architect, iD2 
Technologies</FONT></FONT> <BR><FONT face=Arial 
size=2>[email-masked], <A href="http://www.id2tech.com/" 
target=_blank><FONT color=#000000>http://www.iD2tech.com/</FONT></A></FONT> 
<BR><FONT face=Arial size=2>voice +46 8 7755225, cell +46 70 3198319, fax +46 8 
7267912</FONT> <BR><FONT face=Arial size=2>European IT-prize grand winners 1998 
-- <A href="http://www.it-prize.org/" target=_blank><FONT 
color=#000000>http://www.it-prize.org</FONT></A></FONT> <BR><FONT face=Arial 
size=2>AU-System Group Swedish IT-company of the year 1999</FONT> 
</P></DIV></BODY></HTML>

------_=_NextPart_001_01BF7EE0.C4E602F0--

From: Ambarish Malpani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Thu, 24 Feb 2000 07:44:03 -0800

Hi Guys,
    As I understand it, the requirements for a certificate to
be considered valid according to the German Digital Signature
Act are:

1. The certificate has been created and signed by the CA
2. It is publicly available (if the certificate holder allows).

There was another benefit desired, where a client be able to
query the status of a certificate, where, while querying, it
might not have the CA's public key.

This was translated into an OCSP request where:
a. The request may be made with the hash of the CA's public key
set to 0/all 0's
b. The response would contain the real hash of the CA's public key
c. The responder (VA) verify that the cert was contained in "the"
directory.

Comments
--------
- I believe the requirement to force the VA to check that the
cert is in the directory was to prevent the VA from issuing
incorrect responses (where a cert has been signed, but not
added in the directory)

Issues
------
I. IMPORTANT: If a client be allowed to make a query for a
certificate where it hasn't checked the signature, it could
be making a query for a certificate that doesn't exist (because
the signature on it is bad). The responder might still say the
certificate is good, because, ANOTHER CERTIFICATE WITH THE SAME
SERIAL NUMBER WAS ISSUED AND IS IN THE DIRECTORY!

II. The "publicly available" clause needs to be carefully
interpreted. I don't think it makes sense to force the VA
to try and retrieve the certificate in question from a
directory, because you *will* hit the situation where a
certificate was, in fact correctly issued, but because of
some transient network/machine problem, the VA can't get to
the repository for an instant in time. In that case, should
the VA return a status of bad/revoked/unknown/good? Which of
the responses is "correct"?

Recommendations
---------------
i) Require clients to verify the signature on the certificate
and its validity (ie. in the notBefore and notAfter period)
when the make the query [caveat: the cert might have expired,
in which case you need to check the ArchiveCutoff in the response].
This job needs to be done by the client to ensure that the
query is a reasonable one.

ii) Enforce the publicly available requirement by policy and
procedure. Don't try to enforce that with software.

Does this make sense?

Regards,
Ambarish

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

> -----Original Message-----
> From: Stefan Kelm [mailto:[email-masked]]
> Sent: Thursday, February 24, 2000 5:48 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: German Law and OCSP
> 
> 
> Denis,
> 
> > > Once such a division is made technically, it was extended 
> to the idea
> > > that a certificate should only be valid once it is inserted in the
> > > information service database.
> >
> > I do not understand. To be "valid" a certificate does not (even)
> > have to be published. It may be given back to the user who may
> > decide to send it to whatever entity he wishes.
> 
> you're certainly right. However, the German Digital Signature 
> Act states:
> [from http://www.iid.de/rahmen/iukdgebt.html#a3]
> 
> § 5: Issue of Certificates
> 
> (1) The certification authority shall reliably establish the 
> identity of persons applying for a
> certificate. It shall confirm the assignment of a public 
> signature key to an identified person
> by a signature key certificate which, together with any 
> attribute certificates, shall be kept
> available for verification and, with the consent of the owner 
> of the signature key, for
> retrieval at all times and for everyone over publicly 
> available telecommunication links.
> 
> The magic statement here is "...shall be kept available for 
> verification...
> at all times...". Therefore, a certificate implicitly is 
> valid once it is
> made available (from the CA's repository) for verification. Like it or
> not (I don't) - that's the way the validity model was chosen 
> to be. E.g., I've
> been issued one of the very few certificates issued according 
> to the law
> but since it has not been published yet it is not valid in the sense
> of the law...
> 
> The law currently is under evaluation and will be revised later this
> year. It's highly unlikely that they're going to change this validity
> model, though.
> 
> Cheers,
> 
>         Stefan.
> 
> ______________________________________________________________
> ________________
> Stefan Kelm            PGP key: "finger [email-masked]" 
> or via key server
> DFN-PCA                                                      
> <[email-masked]>
> Vogt-Koelln-Str. 30                               
> http://www.pca.dfn.de/~kelm/
> 22527 Hamburg (Germany)                   Tel: +49 40 428 
> 83-2262 / Fax: -2241
> 

From: "Hesse, Johan" <[email-masked]>
To: [email-masked]
Subject: Re: OCSP and German Law
Date: Thu, 24 Feb 2000 16:32:26 +0100

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_01BF7EDC.787D0640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello!

I agree to Stefan, I bet a box of beer that the "validity model" in the
German Law won't change.

We accompanied TrustCenter which are conform to German Law and we saw =
that
this validity model has an advantage (maybe this is the rational of the
model). Since everyone seems to be unhappy with this validity model =
lets
mention the advantage to the honour of the good old law.
But please don't flame me, because I'm sure that there are other =
(better?)
possibilities.=20

The advantage is more or less of legal and/or organizational nature. If =
the
CA signs a certificate, the PSE (e.g. your smart card with your =
*private*
key) has to be delivered in a secure way to the owner.=20

In technical terms the certificate is almost valid (but not in legal =
terms).
But the PSE hasn't handed out to the owner yet, - with all =
possibilities of
abuse (I know there are ways to handle it in another way). But if you =
wait
until the owner proofs that he received the PSE, to say the certificate =
is
valid you avoid this insecure time gap. The validation is manifested by
publishing the certificate.

So I hope you see the rational of this validity model.

   Cheers,

               Johan

P.s.: I wait if somone wants to bet. I propose we drink the beer =
together, -
lets say at the CeBit 2001.

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : +49 (0)40/696599-12
> Fax   : +49 (0)40/696599-29
> mailto:[email-masked]
> **************************************
>=20
>=20

------_=_NextPart_001_01BF7EDC.787D0640
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Re: OCSP and German Law</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree to Stefan, I bet a box of beer =
that the &quot;validity model&quot; in the German Law won't =
change.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We accompanied TrustCenter which are =
conform to German Law and we saw that this validity model has an =
advantage (maybe this is the rational of the model). Since everyone =
seems to be unhappy with this validity model lets mention the advantage =
to the honour of the good old law.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But please don't flame me, because I'm =
sure that there are other (better?) possibilities. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The advantage is more or less of legal =
and/or organizational nature. If the CA signs a certificate, the PSE =
(e.g. your smart card with your *private* key) has to be delivered in a =
secure way to the owner. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In technical terms the certificate is =
almost valid (but not in legal terms). But the PSE hasn't handed out to =
the owner yet, - with all possibilities of abuse (I know there are ways =
to handle it in another way). But if you wait until the owner proofs =
that he received the PSE, to say the certificate is valid you avoid =
this insecure time gap. The validation is manifested by publishing the =
certificate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So I hope you see the rational of this =
validity model.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Johan</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P.s.: I wait if somone wants to bet. I =
propose we drink the beer together, - lets say at the CeBit =
2001.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7EDC.787D0640--

Date: Thu, 24 Feb 2000 16:04:45 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
Subject: Re: German Law and OCSP

Stefan,

Thanks for your comment. See my comments next.
 
> Denis,
> 
> > > Once such a division is made technically, it was extended to the idea
> > > that a certificate should only be valid once it is inserted in the
> > > information service database.
> >
> > I do not understand. To be "valid" a certificate does not (even)
> > have to be published. It may be given back to the user who may
> > decide to send it to whatever entity he wishes.
> 
> you're certainly right. However, the German Digital Signature Act states:
> [from http://www.iid.de/rahmen/iukdgebt.html#a3]
> 
> § 5: Issue of Certificates
> 
> (1) The certification authority shall reliably establish the identity of persons applying for a
> certificate. It shall confirm the assignment of a public signature key to an identified person
> by a signature key certificate which, together with any attribute certificates, shall be kept
> available for verification and, with the consent of the owner of the signature key, for
> retrieval at all times and for everyone over publicly available telecommunication links.
> 
> The magic statement here is "...shall be kept available for verification...
> at all times...". Therefore, a certificate implicitly is valid once it is
> made available (from the CA's repository) for verification. 

The other magic statement is: "with the consent of the owner of the
signature key". If there is no such consent, then the statement does
not apply, hence there is no publication.

"kept available for verification" does not imply any publication. It
means that the AC must keep a local copy.

Besides the wording, the question was to understand the rational of
the model. The question is still pending ...

Regards,

Denis

> Like it or
> not (I don't) - that's the way the validity model was chosen to be. E.g., I've
> been issued one of the very few certificates issued according to the law
> but since it has not been published yet it is not valid in the sense
> of the law...
> 
> The law currently is under evaluation and will be revised later this
> year. It's highly unlikely that they're going to change this validity
> model, though.
> 
> Cheers,
> 
>         Stefan.
> 
> ______________________________________________________________________________
> Stefan Kelm            PGP key: "finger [email-masked]" or via key server
> DFN-PCA                                                      <[email-masked]>
> Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
> 22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241

Date: Wed, 23 Feb 2000 17:37:35 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: <[email-masked]>, <[email-masked]>

--============_-1260717979==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,
	<snip>

>Not abandon, a DN would still be a DN.  Heritage is of less interest.
>The solution is a technical way to solve something that is already 
>performed using
>"local knowledge and manual settings" by a lot of current RP software.

A DN is a directory distinguished name, not just an arbitrary 
sequence of sets of attributes.

>As compatibility with existing SW is crucial, some purity will have 
>to be sacrificed.
>For radical changes like GNs it may be better to look on XML-certs 
>but that is another story.

It's not surprising that you are willing to make that tradeoff, but 
that does not constitute a rationale for doing so.  GNs are NOT a 
radical change.  2459 mandates support for several GNs already.  if 
one defined a new GN that used the same set of attributes as a DN, 
then this would be a clean solution that would allow reuse of the 
software that knows how to parse DNs, without muddying the semantics 
of DNs.

	<snip>

>As Denis nicely points out, the suggested solution allows arbitrary uses
>of DN attributes including various combinations with serialNumber and
>lets say organizationUnit.   But for the RP it looks like a singular solution
>as it just requires a call to the (anticipated) API function 
>"getQCUnmistakableIdenitity()"
>to get the optional subset of of DN that holds the unmistakable identity.
>That is what I call GENERIC SOLUTION and is what standards need.

Yes, the proposal allows arbitrary use of DN attributes, which is why 
the result is not longer a DN, and does not belong warrant being 
tagged as a DN.

	<snip>

>Unfortunately NON-STANDARD policy OIDs create much more problems than
>they solve.  I have already elaborated on that in this list.

"non-standard" policy OIDs?  This implies that there is a standard 
set, but I'm not sure where that standard set has been defined.  One 
school of thought assumes that a small set of policy OIDs will come 
into existence, hence the desire for policy qualifiers.  However, 
that is not the only model for use of policy OIDs, so I think your 
reference here is premature, and narrow.

>What is missing from the current suggestion is a Naming Domain definition.
>I can just find two variants: Either the naming domain is marked as 
>internal/CA
>and does not have to be known outside, or the CA issues certificates to
>an external naming domain like "registered Citizen of XYZ".   The 
>latter should
>require an officially registered value of some kind to be interoperable among
>competing CAs,

I think that your suggestion for a name domain definition is further 
evidence that the identifiers that you are referring to are not 
really DNs!

	<snip>

>PS Steve, do you prefer that a solution according to my and Denis lines are
>taken to PKI-FORUM rather than developed here?  I don't care where as
>long as it gets done.  DS

Is this a trick question?  Is it really an offer for you to move your 
campaign for changes to ITU and IETF standards to an industry 
consortium? How can I say no?

Steve

--============_-1260717979==_ma============
Content-Type: text/enriched; charset="us-ascii"

Anders,

	<<snip>

<excerpt>Not abandon, a DN would still be a DN.  Heritage is of less
interest.

The solution is a technical way to solve something that is already
performed using

"local knowledge and manual settings" by a lot of current RP software.

</excerpt>

A DN is a <underline>directory</underline> distinguished name, not just
an arbitrary sequence of sets of attributes. 

<excerpt>As compatibility with existing SW is crucial, some purity will
have to be sacrificed.

For radical changes like GNs it may be better to look on XML-certs but
that is another story.

</excerpt>

It's not surprising that you are willing to make that tradeoff, but
that does not constitute a rationale for doing so.  GNs are NOT a
radical change.  2459 mandates support for several GNs already.  if one
defined a new GN that used the same set of attributes as a DN, then
this would be a clean solution that would allow reuse of the software
that knows how to parse DNs, without muddying the semantics of DNs.

	<<snip>

<excerpt>As Denis nicely points out, the suggested solution allows
arbitrary uses

of DN attributes including various combinations with serialNumber and

lets say organizationUnit.   But for the RP it looks like a singular
solution

as it just requires a call to the (anticipated) API function
"getQCUnmistakableIdenitity()"

to get the optional subset of of DN that holds the unmistakable
identity.

That is what I call GENERIC SOLUTION and is what standards need.

</excerpt>

Yes, the proposal allows arbitrary use of DN attributes, which is why
the result is not longer a DN, and does not belong warrant being tagged
as a DN.

	<<snip>

<excerpt>Unfortunately NON-STANDARD policy OIDs create much more
problems than

they solve.  I have already elaborated on that in this list.

</excerpt>

"non-standard" policy OIDs?  This implies that there is a standard set,
but I'm not sure where that standard set has been defined.  One school
of thought assumes that a small set of policy OIDs will come into
existence, hence the desire for policy qualifiers.  However, that is
not the only model for use of policy OIDs, so I think your reference
here is premature, and narrow.

<excerpt>What is missing from the current suggestion is a Naming Domain
definition.

I can just find two variants: Either the naming domain is marked as
internal/CA

and does not have to be known outside, or the CA issues certificates
to

an external naming domain like "registered Citizen of XYZ".   The
latter should

require an officially registered value of some kind to be interoperable
among

competing CAs,

</excerpt>

I think that your suggestion for a name domain definition is further
evidence that the identifiers that you are referring to are not really
DNs!

	<<snip>

<excerpt>PS Steve, do you prefer that a solution according to my and
Denis lines are

taken to PKI-FORUM rather than developed here?  I don't care where as

long as it gets done.  DS

</excerpt>

Is this a trick question?  Is it really an offer for you to move your
campaign for changes to ITU and IETF standards to an industry
consortium? How can I say no?

Steve 

--============_-1260717979==_ma============--

Date: Thu, 24 Feb 2000 09:30:23 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Subject: Re: German Law and OCSP

>>>>> "Stefan" == Stefan Kelm <[email-masked]> writes:

 Stefan> Denis,
 >> > Once such a division is made technically, it was extended to the
 >> idea > that a certificate should only be valid once it is inserted
 >> in the > information service database.
 >> 
 >> I do not understand. To be "valid" a certificate does not (even)
 >> have to be published. It may be given back to the user who may
 >> decide to send it to whatever entity he wishes.

 Stefan> you're certainly right. However, the German Digital Signature
 Stefan> Act states: [from http://www.iid.de/rahmen/iukdgebt.html#a3]

 Stefan> § 5: Issue of Certificates

 Stefan> (1) The certification authority shall reliably establish the
 Stefan> identity of persons applying for a certificate. It shall
 Stefan> confirm the assignment of a public signature key to an
 Stefan> identified person by a signature key certificate which,
 Stefan> together with any attribute certificates, shall be kept
 Stefan> available for verification and, with the consent of the owner
 Stefan> of the signature key, for retrieval at all times and for
 Stefan> everyone over publicly available telecommunication links.

 Stefan> The magic statement here is "...shall be kept available for
 Stefan> verification...  at all times...". Therefore, a certificate
 Stefan> implicitly is valid once it is made available (from the CA's
 Stefan> repository) for verification. Like it or not (I don't) -
 Stefan> that's the way the validity model was chosen to be. E.g.,
 Stefan> I've been issued one of the very few certificates issued
 Stefan> according to the law but since it has not been published yet
 Stefan> it is not valid in the sense of the law...

I think that may be a matter of interpretation.  The english
translation is ambiguous as to whether "at all times and for everyone" 
applies to retrieval only, or also to verification.  The original
makes it clear the latter is correct.

One way of reading that is "any person should be able to verify the
validity of the certificate; if any communication channels are needed
for this, public one should suffice".  The standard algorithm of
checking the CA signature and the CRL is an example of such a process, 
assuming that the current CRL is available over public communications
channels.  

	paul

Date: Thu, 24 Feb 2000 14:47:31 +0100 (MET)
From: Stefan Kelm <[email-masked]>
To: [email-masked]
Subject: Re: German Law and OCSP
Cc: [email-masked]
Reply-To: [email-masked]

Denis,

> > Once such a division is made technically, it was extended to the idea
> > that a certificate should only be valid once it is inserted in the
> > information service database.
>
> I do not understand. To be "valid" a certificate does not (even)
> have to be published. It may be given back to the user who may
> decide to send it to whatever entity he wishes.

you're certainly right. However, the German Digital Signature Act states:
[from http://www.iid.de/rahmen/iukdgebt.html#a3]

§ 5: Issue of Certificates

(1) The certification authority shall reliably establish the identity of persons applying for a
certificate. It shall confirm the assignment of a public signature key to an identified person
by a signature key certificate which, together with any attribute certificates, shall be kept
available for verification and, with the consent of the owner of the signature key, for
retrieval at all times and for everyone over publicly available telecommunication links.

The magic statement here is "...shall be kept available for verification...
at all times...". Therefore, a certificate implicitly is valid once it is
made available (from the CA's repository) for verification. Like it or
not (I don't) - that's the way the validity model was chosen to be. E.g., I've
been issued one of the very few certificates issued according to the law
but since it has not been published yet it is not valid in the sense
of the law...

The law currently is under evaluation and will be revised later this
year. It's highly unlikely that they're going to change this validity
model, though.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email-masked]" or via key server
DFN-PCA                                                      <[email-masked]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)                   Tel: +49 40 428 83-2262 / Fax: -2241

From: "Hesse, Johan" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: German Law and OCSP
Date: Thu, 24 Feb 2000 14:37:23 +0100

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_01BF7ECC.ADF06180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello out there!

It seems that there are a lot of confusions regarding some terms in the
German Law.
As considered there are two distinct entities. One for issuing =
certificates
and one for revoking certificates. The revocation is maintained by the
directory service (DIR, Andreas Berger described it with "information
service"). In the moment the issuing entity signs a certificate you may =
be
attempted to say its valid, but in the sense of German Law a valid
certificate has to be published. Published in this coherence means that =
the
certificate is either *checkable* (you can only get status information) =
or
*retrievable* (you can get status information and the whole =
certificate).
Both status have to be maintained by the DIR.

I think the confusion springs from legal terms. In the above mentioned
example the technical term of *valid* for a certificate would be the =
moment
of the signing with the signing key. The legal term assumes the =
publishing
of the certificate.

Another misunderstanding seems to be the role of the CRL in German Law. =

Antonio Lioy wrote (28.01.2000) "... the only legally binding way to =
prove
that a cert was not valid at a certain date is to provide a CRL (or a
CSL!!!) that includes it." The German Law requires only the =
*checkability*
of the status of a certificate for anybody to any time (=A74 SigG). The
interoperability schemes (SigI A5) propose OCSP. The status =
*suspension*
isn't allowed according to the German Law, in comparision with Italian =
law
which requires a CRL (Art. 29 par. 3) and the possibility of suspension
(Art. 33).

   Best regards,  =20
                        Johan Hesse

> **************************************
> Johan Hesse
> secunet=20
> Security Networks AG    =20
> Osterbekstra=DFe 90b
> 22083 Hamburg
> =20
> Tel   : +49 (0)40/696599-12
> Fax   : +49 (0)40/696599-29
> mailto:[email-masked]
> **************************************
>=20
>=20

------_=_NextPart_001_01BF7ECC.ADF06180
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Re: German Law and OCSP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello out there!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It seems that there are a lot of =
confusions regarding some terms in the German Law.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As considered there are two distinct =
entities. One for issuing certificates and one for revoking =
certificates. The revocation is maintained by the directory service =
(DIR, Andreas Berger described it with &quot;information =
service&quot;). In the moment the issuing entity signs a certificate =
you may be attempted to say its valid, but in the sense of German Law a =
valid certificate has to be published. Published in this coherence =
means that the certificate is either *checkable* (you can only get =
status information) or *retrievable* (you can get status information =
and the whole certificate). Both status have to be maintained by the =
DIR.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think the confusion springs from =
legal terms. In the above mentioned example the technical term of =
*valid* for a certificate would be the moment of the signing with the =
signing key. The legal term assumes the publishing of the =
certificate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another misunderstanding seems to be =
the role of the CRL in German Law. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Antonio Lioy wrote (28.01.2000) =
&quot;... the only legally binding way to prove that a cert was not =
valid at a certain date is to provide a CRL (or a CSL!!!) that includes =
it.&quot; The German Law requires only the *checkability* of the status =
of a certificate for anybody to any time (=A74 SigG). The =
interoperability schemes (SigI A5) propose OCSP. The status =
*suspension* isn't allowed according to the German Law, in comparision =
with Italian law which requires a CRL (Art. 29 par. 3) and the =
possibility of suspension (Art. 33).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Best regards,&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Johan Hesse</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">Johan Hesse</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Tahoma">secu</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Tahoma">net </FONT></B>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Security Networks =
AG&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Osterbekstra=DFe 90b</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22083 Hamburg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Tel&nbsp;&nbsp; : +49 =
(0)40/696599-12</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Fax&nbsp;&nbsp; : +49 =
(0)40/696599-29</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A></FONT><=
/U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">**************************************</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BF7ECC.ADF06180--

Date: Thu, 24 Feb 2000 09:55:23 +0100
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
CC: [email-masked]
Subject: Re: Straw Poll: SerialNumber definition

Bengt Ohlsson wrote:
> 
> Stefan,
> 
> I think there is an even simpler solution to the problem
> by using the SubjectAltName extension. Just take those
> RDNs that are required to make the name unique and
> use those RDNs as a directoryName entry in the
> SubjectAltName extension. E.g. if the serialNumber
> attribute is unique by itself, then the SubjectAltName
> entry will only contain the serialNumber. This also allows
> for a QC to contain different forms of unique names for
> the same subject.
> 
> This will not affect any existing applications, since no
> new attributes are instroduced. New applications that
> will use QC can use the SubjectAltName extension to
> find a name that is usable for the application.

I support this position.

We have already used the subjectAltName extension and we are
quite satisfied with it. In fact we can have more than one
of it, to insert into the certificate a variety of SN or
unique identifiers.
For example, we use it to insert our unique University ID
but a second extension could be added for standard Italian
national personal code, or for the case where the same
individual belongs to two different organizations.

Each subjectAltName is distinguished by a unique OID and
hence each application can look for the one that it is able
to deal with.

This goes in the line of having just one certificate for
person, instead of forcing people to have multiple
certificates for multiple applications.

Antonio Lioy

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 09:29:09 -0000

David,
Although I like the simplicity of the scheme it does IMO limit the ways you
can express Unmistakable Identity (UI).

I am not sure (since my X500 is rather sluggish) but it seems that you may have to move
around RDNs in order to create what you want. Do we want that?  

Let's say
DN = CN + [OU + SN]        ;Organization Unit and Serial Number
DN = CN + [SN] + OU       ; Only serial number (Swedish EID)
DN = [CN+SN] + OU        ; Probably name disambiguer usage

The [] indicates UI.   Is that compatible with this single boolean of yours?
BTW, can't an e-mail address also serve as a UI?

Conclusion: Denis' orginal position-oriented BITSTRING is more universal and
can even be applied to private RDNs.

Anders

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Wednesday, February 23, 2000 22:10
Subject: Re: Straw Poll: SerialNumber definition

>
>> From: Denis Pinkas <[email-masked]>
>> 
>> The solution to use the certPolicy OID proposed by Steve would not
>> work for an automated processing.
>> The solution proposed by Stefan would work, but I have something
>> simpler (but less flexible) that could possibly work.
>
>Simpler is better. :-)
>
>
>> The idea is that the *relative* placement of the UI in the DN chain
>> indicates to what it applies. In other words it serves like a
>> delimiter. Everything on the left of the delimiter has to be used to
>> make the name unique and permanent, for the given CA. If it comes
>> first, then it is self-sufficient by itself (e.g. it could be a
>> social security number or an employee number). In the following
>> example, it would only apply to G, I and S but not to O.
>> 
>> G=; I=; S=; UI= ; O=;
>> 
>> What do you think ?
>
>
>This solution presupposes that X.509 DNs do not have a one-to-one
>correspondence with the directory tree.  The last time a similar scheme
>came up in this thread, it was remarked that there is/should-be a
>direct mapping between the entire X.509 Distinguished Name and the
>directory. The two certs:
>
>  (1)   CN=; SN=; OU=; O=; C=;
>  (2)   CN= + SN=; OU=; O=; C=;
>
>would be stored as follows in the DIT:
>
>          (1)                       (2)
>
>           C                         C
>          / \                       / \
>         O   O                     O   O
>        / |  | \                  / |  | \
>       OU                        OU
>      /  \                      /  \
>     SN                      SN+CN
>     |
>     CN
>
>The problem with cert (1) is that it creates an additional layer
>in the directory where each SN node has only a single child.  The
>problem with cert (2) is that it does not specify whether the value
>of CN is a significant part of the subject's identity or just a
>human-readable comment.
>
>If a "delimiter" UI attribute were defined, cert (1) could have five
>single-AT&V RDNs but still be stored in a four-level directory structure:
>
>                              (1)
>
>                               C
>                              / \
>                             O   O
>                            / |  | \
>                           OU
>                          /  \
>           delimiter ->  UI
> (remainder of DN is
> just human-readable
> information)
> 
>
>Stefan previously suggested five alternatives for the static
>identifier, each of which had advantages and disadvantages.  At that
>time the creation of a new RDN attribute was deemed less desirable than
>using the existing SN attribute.  I don't believe the situation leading
>to that decision has changed.
>
>However, Stefan's suggestion to use a dnIdentityMask contained in
>the QC Statements extension can be simplified along the lines suggested
>by Denis and Peter Sylvester without requiring a new RDN attribute.
>All that is needed is a boolean signal indicating if the SN attribute
>is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
>additional AT&Vs in the current RDN are treated as comments, not part
>of the "DN Identity" or directory structure.  If absent or FALSE, the
>SN attribute is not treated as a delimiter.
>
>The form of the signal is immaterial. I believe it can be contained
>implicitly within Cert Policies OIDs, Anders believes an explicit
>signal is necessary; both views can be accommodated by defining an
>optional boolean field somewhere within the QC Statements extension.
>
>As an example, one could replace Stefan's
>
>>       SemanticsInformation ::= SEQUENCE {
>>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>>           nameRegistrationAuthorities NameRegistrationAuthorities
>>                                                           OPTIONAL
>>           dnIdentityMask              DnIdentityMask   OPTIONAL}
>>
>>           DnIdentityMask ::= BIT STRING {
>>                countryName             (0),
>>                commonName              (1),
>>                surname                 (2),
>>                givenName               (3),
>>                pseudonym               (4),
>>                serialNumber            (5),
>>                organizationName        (6),
>>                organizationalUnitName  (7),
>>                stateOrProvinceName     (8),
>>                localityName            (9),
>>                postalAddress          (10)}
>
>
>with
>
>>       SemanticsInformation ::= SEQUENCE {
>>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>>           nameRegistrationAuthorities NameRegistrationAuthorities
>>                                                           OPTIONAL
>>           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
>The advantage of using a "delimiter signal" or "static UID signal" with
>SN instead of defining a new RDN attribute is the same as before - it
>maximizes interoperability with existing certificates and
>applications.  Many applications are getting along quite well using
>multi-value RDNs and application-defined treatment of "affiliation
>numbers".  These applications will continue to work with certs
>containing a non-critical QC Statements extension; they would be broken
>by a new RDN attribute.
>
>Stefan and the WG chairs can decide if it is appropriate to be munging
>syntax during Last Call :-).  If we can't reach quick agreement, I
>believe definition of a static UID signal should be deferred to the
>next QC iteration and the current draft should proceed to RFC.

From: "Anders Rundgren" <[email-masked]>
To: "Bengt Ohlsson" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 09:25:07 -0000

Bengt,

<snip>

>This will not affect any existing applications, since no
>new attributes are instroduced. New applications that
>will use QC can use the SubjectAltName extension to
>find a name that is usable for the application.

The idea is (in my opinion at least) that existing aplication should continue to work
as this must be an uncritical extension.  But that new applications should see this
extension as the signal: "Plug'nPlay Certificate".   That requires though that the
NAMING DOMAIN issue is also covered by this extension.

Anders

From: Bengt Ohlsson <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, [email-masked]
Subject: RE: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 09:10:13 +0100

Stefan,

I think there is an even simpler solution to the problem
by using the SubjectAltName extension. Just take those
RDNs that are required to make the name unique and
use those RDNs as a directoryName entry in the
SubjectAltName extension. E.g. if the serialNumber 
attribute is unique by itself, then the SubjectAltName
entry will only contain the serialNumber. This also allows
for a QC to contain different forms of unique names for
the same subject.

This will not affect any existing applications, since no
new attributes are instroduced. New applications that
will use QC can use the SubjectAltName extension to
find a name that is usable for the application.

/Bengt

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: den 24 februari 2000 01:16
To: 'David P. Kemp'; [email-masked]; [email-masked]
Subject: RE: Straw Poll: SerialNumber definition

David,

Your proposal seams like a nice, simple and reasonable solution.
Lets see if it can gain support from the critical eyes on this list. If so
then I can live with it.

-----
Caution Note to those participating in this thread: Please avoid cross
postings to other lists (such as SEIS and EL-SIGN) since it gets rather
nasty when people make "reply to all" on the postings. I have already got
complaints from people on the EL-SIGN list. So when replying to these
postings, please remove other lists from the recipient header.

/Stefan

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 11:03 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
>
> > From: Denis Pinkas <[email-masked]>
> >
> > The solution to use the certPolicy OID proposed by Steve would not
> > work for an automated processing.
> > The solution proposed by Stefan would work, but I have something
> > simpler (but less flexible) that could possibly work.
>
> Simpler is better. :-)
>
>
> > The idea is that the *relative* placement of the UI in the DN chain
> > indicates to what it applies. In other words it serves like a
> > delimiter. Everything on the left of the delimiter has to be used to
> > make the name unique and permanent, for the given CA. If it comes
> > first, then it is self-sufficient by itself (e.g. it could be a
> > social security number or an employee number). In the following
> > example, it would only apply to G, I and S but not to O.
> >
> > G=; I=; S=; UI= ; O=;
> >
> > What do you think ?
>
>
> This solution presupposes that X.509 DNs do not have a one-to-one
> correspondence with the directory tree.  The last time a
> similar scheme
> came up in this thread, it was remarked that there is/should-be a
> direct mapping between the entire X.509 Distinguished Name and the
> directory. The two certs:
>
>   (1)   CN=; SN=; OU=; O=; C=;
>   (2)   CN= + SN=; OU=; O=; C=;
>
> would be stored as follows in the DIT:
>
>           (1)                       (2)
>
>            C                         C
>           / \                       / \
>          O   O                     O   O
>         / |  | \                  / |  | \
>        OU                        OU
>       /  \                      /  \
>      SN                      SN+CN
>      |
>      CN
>
> The problem with cert (1) is that it creates an additional layer
> in the directory where each SN node has only a single child.  The
> problem with cert (2) is that it does not specify whether the value
> of CN is a significant part of the subject's identity or just a
> human-readable comment.
>
> If a "delimiter" UI attribute were defined, cert (1) could have five
> single-AT&V RDNs but still be stored in a four-level
> directory structure:
>
>                               (1)
>
>                                C
>                               / \
>                              O   O
>                             / |  | \
>                            OU
>                           /  \
>            delimiter ->  UI
>  (remainder of DN is
>  just human-readable
>  information)
>
>
> Stefan previously suggested five alternatives for the static
> identifier, each of which had advantages and disadvantages.  At that
> time the creation of a new RDN attribute was deemed less
> desirable than
> using the existing SN attribute.  I don't believe the
> situation leading
> to that decision has changed.
>
> However, Stefan's suggestion to use a dnIdentityMask contained in
> the QC Statements extension can be simplified along the lines
> suggested
> by Denis and Peter Sylvester without requiring a new RDN attribute.
> All that is needed is a boolean signal indicating if the SN attribute
> is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
> additional AT&Vs in the current RDN are treated as comments, not part
> of the "DN Identity" or directory structure.  If absent or FALSE, the
> SN attribute is not treated as a delimiter.
>
> The form of the signal is immaterial. I believe it can be contained
> implicitly within Cert Policies OIDs, Anders believes an explicit
> signal is necessary; both views can be accommodated by defining an
> optional boolean field somewhere within the QC Statements extension.
>
> As an example, one could replace Stefan's
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
>
>
> with
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
> The advantage of using a "delimiter signal" or "static UID
> signal" with
> SN instead of defining a new RDN attribute is the same as before - it
> maximizes interoperability with existing certificates and
> applications.  Many applications are getting along quite well using
> multi-value RDNs and application-defined treatment of "affiliation
> numbers".  These applications will continue to work with certs
> containing a non-critical QC Statements extension; they would
> be broken
> by a new RDN attribute.
>
> Stefan and the WG chairs can decide if it is appropriate to be munging
> syntax during Last Call :-).  If we can't reach quick agreement, I
> believe definition of a static UID signal should be deferred to the
> next QC iteration and the current draft should proceed to RFC.
>

From: "Dulude, Bob" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Wed, 23 Feb 2000 21:37:25 -0500

unsubscribe

From: "Stefan Santesson" <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Thu, 24 Feb 2000 01:16:03 +0100
Importance: Normal

David,

Your proposal seams like a nice, simple and reasonable solution.
Lets see if it can gain support from the critical eyes on this list. If so
then I can live with it.

-----
Caution Note to those participating in this thread: Please avoid cross
postings to other lists (such as SEIS and EL-SIGN) since it gets rather
nasty when people make "reply to all" on the postings. I have already got
complaints from people on the EL-SIGN list. So when replying to these
postings, please remove other lists from the recipient header.

/Stefan

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 11:03 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
>
> > From: Denis Pinkas <[email-masked]>
> >
> > The solution to use the certPolicy OID proposed by Steve would not
> > work for an automated processing.
> > The solution proposed by Stefan would work, but I have something
> > simpler (but less flexible) that could possibly work.
>
> Simpler is better. :-)
>
>
> > The idea is that the *relative* placement of the UI in the DN chain
> > indicates to what it applies. In other words it serves like a
> > delimiter. Everything on the left of the delimiter has to be used to
> > make the name unique and permanent, for the given CA. If it comes
> > first, then it is self-sufficient by itself (e.g. it could be a
> > social security number or an employee number). In the following
> > example, it would only apply to G, I and S but not to O.
> >
> > G=; I=; S=; UI= ; O=;
> >
> > What do you think ?
>
>
> This solution presupposes that X.509 DNs do not have a one-to-one
> correspondence with the directory tree.  The last time a
> similar scheme
> came up in this thread, it was remarked that there is/should-be a
> direct mapping between the entire X.509 Distinguished Name and the
> directory. The two certs:
>
>   (1)   CN=; SN=; OU=; O=; C=;
>   (2)   CN= + SN=; OU=; O=; C=;
>
> would be stored as follows in the DIT:
>
>           (1)                       (2)
>
>            C                         C
>           / \                       / \
>          O   O                     O   O
>         / |  | \                  / |  | \
>        OU                        OU
>       /  \                      /  \
>      SN                      SN+CN
>      |
>      CN
>
> The problem with cert (1) is that it creates an additional layer
> in the directory where each SN node has only a single child.  The
> problem with cert (2) is that it does not specify whether the value
> of CN is a significant part of the subject's identity or just a
> human-readable comment.
>
> If a "delimiter" UI attribute were defined, cert (1) could have five
> single-AT&V RDNs but still be stored in a four-level
> directory structure:
>
>                               (1)
>
>                                C
>                               / \
>                              O   O
>                             / |  | \
>                            OU
>                           /  \
>            delimiter ->  UI
>  (remainder of DN is
>  just human-readable
>  information)
>
>
> Stefan previously suggested five alternatives for the static
> identifier, each of which had advantages and disadvantages.  At that
> time the creation of a new RDN attribute was deemed less
> desirable than
> using the existing SN attribute.  I don't believe the
> situation leading
> to that decision has changed.
>
> However, Stefan's suggestion to use a dnIdentityMask contained in
> the QC Statements extension can be simplified along the lines
> suggested
> by Denis and Peter Sylvester without requiring a new RDN attribute.
> All that is needed is a boolean signal indicating if the SN attribute
> is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
> additional AT&Vs in the current RDN are treated as comments, not part
> of the "DN Identity" or directory structure.  If absent or FALSE, the
> SN attribute is not treated as a delimiter.
>
> The form of the signal is immaterial. I believe it can be contained
> implicitly within Cert Policies OIDs, Anders believes an explicit
> signal is necessary; both views can be accommodated by defining an
> optional boolean field somewhere within the QC Statements extension.
>
> As an example, one could replace Stefan's
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
>
>
> with
>
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           snIsDelimiter              BOOLEAN DEFAULT FALSE}
>
>
>
> The advantage of using a "delimiter signal" or "static UID
> signal" with
> SN instead of defining a new RDN attribute is the same as before - it
> maximizes interoperability with existing certificates and
> applications.  Many applications are getting along quite well using
> multi-value RDNs and application-defined treatment of "affiliation
> numbers".  These applications will continue to work with certs
> containing a non-critical QC Statements extension; they would
> be broken
> by a new RDN attribute.
>
> Stefan and the WG chairs can decide if it is appropriate to be munging
> syntax during Last Call :-).  If we can't reach quick agreement, I
> believe definition of a static UID signal should be deferred to the
> next QC iteration and the current draft should proceed to RFC.
>

From: "Stefan Santesson" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 19:22:05 +0100
Importance: Normal

Denis,

Let me first state that my solution was not a proposal. I don't know yet if
I like it myself. It was just a solution thrown to the floor for open
consideration. Personally I'm not yet convinced that we have a problem that
should be fixed in the first place.

But anyway, I don't like the solution you you present here by one big
reason, it introduces a new nonstandard attribute in the subject field. That
has been considered before and the principial standpoint is that it should
be avoided.

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 4:19 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
> Since the last call period is now open, let us attempt to
> (hopefully) solve this issue within that period.
>
> The solution to use the certPolicy OID proposed by Steve would not
> work for an automated processing.
> The solution proposed by Stefan would work, but I have something
> simpler (but less flexible) that could possibly work.
>
> Let is take a look at an old INFORMATIONAL RFC, i.e. RFC 1685
> issused in August 1994. Its name is: Writing X.400 O/R Names.
>
> Basically this document *recommends* a sequence for writing
> distinguished names for human beings which is:
>
> G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;
>
> with:
>
>     Given Name                             Given name        G
>     Initial                                Initials          I
>     Surname                                Surname           S
>     Generation Qualifier                   Generation        Q
>     Common Name                            Common Name       CN
>     Organization                           Organization      O
>     Organizational Unit 1                  Org.Unit.1        OU1
>     Organizational Unit 2                  Org.Unit.2        OU2
>     Organizational Unit 3                  Org.Unit.3        OU3
>     Organizational Unit 4                  Org.Unit.4        OU4
>     Private Management Domain Name         PRMD              P
>     Administration Management Domain Name  ADMD              A
>     Country                                Country           C
>
> Suppose that now we introduce the new atribute called
> UniqueIdentifier (UI), instead of SerialNumber which is a little bit
> confusing.
>
> The idea is that the *relative* placement of the UI in the DN chain
> indicates to what it applies. In other words it serves like a
> delimiter. Everything on the left of the delimiter has to be used to
> make the name unique and permanent, for the given CA. If it comes
> first, then it is self-sufficient by itself (e.g. it could be a
> social security number or an employee number). In the following
> example, it would only apply to G, I and S but not to O.
>
> G=; I=; S=; UI= ; O=;
>
> What do you think ?
>
> Denis
>
>
> > Guys,
> >
> > I may have a nice solution to this debate.
> >
> > May I first draw your attention once again to the fact that
> the solution in
> > the qcStatement extension almost have what you ask for in
> the first place.
> >
> > What we have is a predefined statement in QC 03 saying:
> >
> >    3.2.5.1 Predefined Statements
> >
> >    This profile includes one predefined object identifier (id-qcs-
> >    pkixQCSyntax-v1), identifying conformance with syntax
> and semantics
> >    defined in this profile. This Qualified Certificate profile is
> >    referred to as version 1.
> >
> >       qcStatement-1 QC-STATEMENT ::= { SemanticsInformation
> IDENTIFIED
> >           BY id-qcs-pkixQCSyntax-v1 }
> >       --  This statement identifies conformance with syntax and
> >       --  semantics defined in this Qualified Certificate profile
> >       --  (Version 1). The SemanticsInformation may
> optionally contain
> >       --  additional semantics information as specified.
> >
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL }
> >           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
> >            WITH COMPONENTS {...,
> nameRegistrationAuthorities PRESENT})
> >
> >       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
> >           GeneralName
> >
> > This is a predefined statement dedicated to include
> information that would
> > clarify the actual content in the DN attributes.
> > Lets say that we added another optional data element
> "dnIdentityMask" in the
> > samanticsInformation:
> >
> >       SemanticsInformation ::= SEQUENCE {
> >           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
> >           nameRegistrationAuthorities NameRegistrationAuthorities
> >                                                           OPTIONAL
> >           dnIdentityMask              DnIdentityMask   OPTIONAL}
> >
> >           DnIdentityMask ::= BIT STRING {
> >                countryName             (0),
> >                commonName              (1),
> >                surname                 (2),
> >                givenName               (3),
> >                pseudonym               (4),
> >                serialNumber            (5),
> >                organizationName        (6),
> >                organizationalUnitName  (7),
> >                stateOrProvinceName     (8),
> >                localityName            (9),
> >                postalAddress          (10)}
> >
> > The defined meaning of dnIdentitymask would then be to
> specify the minimum
> > set of attributes needed to obtain a unique identity of the
> subject, needed
> > to identify the subject among all subjects handled by the CA.
> >
> > The good side of this solution is that it can be used
> without any need to
> > define a new OID, since the attribute semantics OID is optional.
> >
> > This solution could in a nice way satisfy all needs raised
> in the discussion
> > without breaking any current practice or stretch any
> intended definitions or
> > structures.
> >
> > I guess that this could be considered as a minor
> adjustments to be included
> > without requiring a new last call period.
> >
> > Thoughts, comments?
> >
> > /Stefan
> >
> > > -----Original Message-----
> > > From: Anders Rundgren [mailto:[email-masked]]
> > > Sent: Wednesday, February 23, 2000 10:00 AM
> > > To: Denis Pinkas; Stephen Kent
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Straw Poll: SerialNumber definition
> > >
> > >
> > > Steve,
> > >
> > > <snip>
> > > >I'm opposed to adding a notion of selective marking of RDNs to
> > > >indicate which ones, in concert, really qualify as a DN,
> remembering
> > > >the definition of a DN.  This was the subject of a
> private message
> > > >exchange between Anders and me last week, so I'm happy
> to share my
> > > >thoughts on this topic.
> > > >
> > > >The notion underlying this proposal seems to be that DNs are
> > > >convenient ways to express human readable names, but
> that in using
> > > >them we should abandon all notions of the DIT context from
> > > which they
> > > >emanated.
> > >
> > > Not abandon, a DN would still be a DN.  Heritage is of
> less interest.
> > > The solution is a technical way to solve something that is
> > > already performed using
> > > "local knowledge and manual settings" by a lot of current
> RP software.
> > >
> > > > A purer way to address this need would be to define a new
> > > >name type under general names (we have a couple of
> options for this
> > > >in GNs), but this would not be backward compatible with
> > > existing apps
> > > >that already have some ability to parse DNs, but not all forms of
> > > >GNs, much less a new form.
> > >
> > > As compatibility with existing SW is crucial, some purity
> > > will have to be sacrificed.
> > > For radical changes like GNs it may be better to look on
> > > XML-certs but that is another story.
> > >
> > > <snip>
> > >
> > > >I think a better approach to the base problem that motivated this
> > > >debate is to use an extension that claims to be a unique
> ID for the
> > > >subject, relative to the Issuer.  But, we already have
> such a value,
> > > >in the form of the SubjectUniqueID, if we really want
> this feature!
> > >
> > > As Denis nicely points out, the suggested solution allows
> > > arbitrary uses
> > > of DN attributes including various combinations with
> serialNumber and
> > > lets say organizationUnit.   But for the RP it looks like a
> > > singular solution
> > > as it just requires a call to the (anticipated) API function
> > > "getQCUnmistakableIdenitity()"
> > > to get the optional subset of of DN that holds the
> > > unmistakable identity.
> > > That is what I call GENERIC SOLUTION and is what standards need.
> > >
> > > SubjectUniqueID is a SPECIAL CASE of no general interest.
> > >
> > > <snip>
> > >
> > > >certs contain subject DNs that differ in other attributes?  Well,
> > > >since all the other proposals for selective RDN use require some
> > > >means of signalling RP software, why not use a cert policy
> > > OID?  It's
> > > >just as valid a means of signalling this non-standard
> > > interpretation,
> > > >for the set of RP software that will need to make use of
> this fact.
> > >
> > > Unfortunately NON-STANDARD policy OIDs create much more
> problems than
> > > they solve.  I have already elaborated on that in this list.
> > >
> > > What is missing from the current suggestion is a Naming
> > > Domain definition.
> > > I can just find two variants: Either the naming domain is
> > > marked as internal/CA
> > > and does not have to be known outside, or the CA issues
> > > certificates to
> > > an external naming domain like "registered Citizen of XYZ".
> > > The latter should
> > > require an officially registered value of some kind to be
> > > interoperable among
> > > competing CAs,
> > >
> > > Conclusion: the maintenance and setup of QC RP SW  can be
> > > really greatly simplified!
> > >
> > > OK, it does not solve the actual meaning of OU, CN, and SN
> > > etc. but somewhere you
> > > have to stop!
> > >
> > > Anders
> > >
> > > PS Steve, do you prefer that a solution according to my and
> > > Denis lines are
> > > taken to PKI-FORUM rather than developed here?  I don't
> care where as
> > > long as it gets done.  DS
> > >
> > >
>

Date: Wed, 23 Feb 2000 17:02:55 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
To: [email-masked], [email-masked], [email-masked]
Content-MD5: Nnff4TD6hrkr7Ezu8EONng==

> From: Denis Pinkas <[email-masked]>
> 
> The solution to use the certPolicy OID proposed by Steve would not
> work for an automated processing.
> The solution proposed by Stefan would work, but I have something
> simpler (but less flexible) that could possibly work.

Simpler is better. :-)

> The idea is that the *relative* placement of the UI in the DN chain
> indicates to what it applies. In other words it serves like a
> delimiter. Everything on the left of the delimiter has to be used to
> make the name unique and permanent, for the given CA. If it comes
> first, then it is self-sufficient by itself (e.g. it could be a
> social security number or an employee number). In the following
> example, it would only apply to G, I and S but not to O.
> 
> G=; I=; S=; UI= ; O=;
> 
> What do you think ?

This solution presupposes that X.509 DNs do not have a one-to-one
correspondence with the directory tree.  The last time a similar scheme
came up in this thread, it was remarked that there is/should-be a
direct mapping between the entire X.509 Distinguished Name and the
directory. The two certs:

  (1)   CN=; SN=; OU=; O=; C=;
  (2)   CN= + SN=; OU=; O=; C=;

would be stored as follows in the DIT:

          (1)                       (2)

           C                         C
          / \                       / \
         O   O                     O   O
        / |  | \                  / |  | \
       OU                        OU
      /  \                      /  \
     SN                      SN+CN
     |
     CN

The problem with cert (1) is that it creates an additional layer
in the directory where each SN node has only a single child.  The
problem with cert (2) is that it does not specify whether the value
of CN is a significant part of the subject's identity or just a
human-readable comment.

If a "delimiter" UI attribute were defined, cert (1) could have five
single-AT&V RDNs but still be stored in a four-level directory structure:

                              (1)

                               C
                              / \
                             O   O
                            / |  | \
                           OU
                          /  \
           delimiter ->  UI
 (remainder of DN is
 just human-readable
 information)

Stefan previously suggested five alternatives for the static
identifier, each of which had advantages and disadvantages.  At that
time the creation of a new RDN attribute was deemed less desirable than
using the existing SN attribute.  I don't believe the situation leading
to that decision has changed.

However, Stefan's suggestion to use a dnIdentityMask contained in
the QC Statements extension can be simplified along the lines suggested
by Denis and Peter Sylvester without requiring a new RDN attribute.
All that is needed is a boolean signal indicating if the SN attribute
is to be treated as a delimiter.  If TRUE, all subsequent RDNs and any
additional AT&Vs in the current RDN are treated as comments, not part
of the "DN Identity" or directory structure.  If absent or FALSE, the
SN attribute is not treated as a delimiter.

The form of the signal is immaterial. I believe it can be contained
implicitly within Cert Policies OIDs, Anders believes an explicit
signal is necessary; both views can be accommodated by defining an
optional boolean field somewhere within the QC Statements extension.

As an example, one could replace Stefan's

>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL
>           dnIdentityMask              DnIdentityMask   OPTIONAL}
>
>           DnIdentityMask ::= BIT STRING {
>                countryName             (0),
>                commonName              (1),
>                surname                 (2),
>                givenName               (3),
>                pseudonym               (4),
>                serialNumber            (5),
>                organizationName        (6),
>                organizationalUnitName  (7),
>                stateOrProvinceName     (8),
>                localityName            (9),
>                postalAddress          (10)}

with

>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL
>           snIsDelimiter              BOOLEAN DEFAULT FALSE}

The advantage of using a "delimiter signal" or "static UID signal" with
SN instead of defining a new RDN attribute is the same as before - it
maximizes interoperability with existing certificates and
applications.  Many applications are getting along quite well using
multi-value RDNs and application-defined treatment of "affiliation
numbers".  These applications will continue to work with certs
containing a non-critical QC Statements extension; they would be broken
by a new RDN attribute.

Stefan and the WG chairs can decide if it is appropriate to be munging
syntax during Last Call :-).  If we can't reach quick agreement, I
believe definition of a static UID signal should be deferred to the
next QC iteration and the current draft should proceed to RFC.

From: Peter Sylvester <[email-masked]>
Date: Wed, 23 Feb 2000 20:26:09 +0100 (MET)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Straw Poll: SerialNumber definition
Cc: [email-masked], [email-masked]

> 
> Peter,
> 
> Your solution is of course possible.  That it is easier to explain is one thing.  To
> implement them in SW is fairly equivalent.
> 
> How about a SET of RDN OIDs instead of this BITSTRING?

That won't work, you can one OU that is part of the unique element and another
that is part of changable part. You could do a bitstring to indicate
which position in the sequence is fixed or not for EACH naming scheme. 
(I am not sayin that I like such a complex solution.)

> 
> 
> >Why the hell do we have object identifiers in RDNs, and not
> >numbers? 
BTW: I have been living in France for so many years now that I have
forgotten that a German person normally doesn't use such DIRECT comments. 
in fact it is one French way to say: Please, you might consider to read this. :-)

Regards and have fun.

From: "Anders Rundgren" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 19:34:01 -0000

Peter,

Your solution is of course possible.  That it is easier to explain is one thing.  To
implement them in SW is fairly equivalent.

How about a SET of RDN OIDs instead of this BITSTRING?

The reason I prefer the separate approach is that this QC Statement could
contain a block of things that would help the mecanic
interpretation of certs.  Like naming domain.   Yes, the existence
of this QC Statement could signify: "Plug'nPlay Certificate".

Anders

>Why the hell do we have object identifiers in RDNs, and not
>numbers? 
>
>> 
>>           DnIdentityMask ::= BIT STRING {
>>                countryName             (0),
>>                commonName              (1),
>>                surname                 (2),
>>                givenName               (3),
>>                pseudonym               (4),
>>                serialNumber            (5),
>>                organizationName        (6),
>>                organizationalUnitName  (7),
>>                stateOrProvinceName     (8),
>>                localityName            (9),
>>                postalAddress          (10)}
>
>It seems that the most simple solution is to add a new attribute
>'the at-sign', or the stop sign. The attribute has no possible
>values, its placement inside the RDN SEQUENCE indicates that everything
>before defines the unique entity. 
>
<snip>

From: Peter Sylvester <[email-masked]>
Date: Wed, 23 Feb 2000 19:18:11 +0100 (MET)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Straw Poll: SerialNumber definition
Cc: [email-masked], [email-masked]

Why the hell do we have object identifiers in RDNs, and not
numbers? 

> 
>           DnIdentityMask ::= BIT STRING {
>                countryName             (0),
>                commonName              (1),
>                surname                 (2),
>                givenName               (3),
>                pseudonym               (4),
>                serialNumber            (5),
>                organizationName        (6),
>                organizationalUnitName  (7),
>                stateOrProvinceName     (8),
>                localityName            (9),
>                postalAddress          (10)}

It seems that the most simple solution is to add a new attribute
'the at-sign', or the stop sign. The attribute has no possible
values, its placement inside the RDN SEQUENCE indicates that everything
before defines the unique entity. 

At a first glance on might think to create an attribute that contains
some value (like serialnumber or unique id). but there is no need
to combine these different two functions, and it is even stupid,
because it might not even be necessary to have a Serialnumber. 

Of course the approach doesn't handle ALL posible theoretical cases
like multi-valued AVAs. And in some cases you need to reverse some
schema in order to have the right hierarchy. Who cares?

Peter Sylvester 

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Plug'nPlay Certificates.  Was: SerialNumber definition
Date: Wed, 23 Feb 2000 17:13:59 -0000

Stefan,
I keep my fingers crossed.

<snip>

>This is a predefined statement dedicated to include information that would
>clarify the actual content in the DN attributes.
>Lets say that we added another optional data element "dnIdentityMask" in the
>samanticsInformation:
>
>
>      SemanticsInformation ::= SEQUENCE {
>          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>          nameRegistrationAuthorities NameRegistrationAuthorities
>                                                          OPTIONAL
>          dnIdentityMask              DnIdentityMask   OPTIONAL}
>
>          DnIdentityMask ::= BIT STRING {
>               countryName             (0),
>               commonName              (1),
>               surname                 (2),
>               givenName               (3),
>               pseudonym               (4),
>               serialNumber            (5),
>               organizationName        (6),
>               organizationalUnitName  (7),
>               stateOrProvinceName     (8),
>               localityName            (9),
>               postalAddress          (10)}
>
>
>The defined meaning of dnIdentitymask would then be to specify the minimum
>set of attributes needed to obtain a unique identity of the subject, needed
>to identify the subject among all subjects handled by the CA.

Is not this not (in principle at least) exactly what Denis (and I in less formal way) suggested and 
was immediately rejected by others?

Well, if you REALLY plan to do changes what do you think of the Naming Domain addition I proposed
that should complement the package to allow what I would call Plug'nPlay Certificates?

What do you think of the impact of such a statement on cert comparisions? I (and Denis?)
think that existence such a statement should directly (or implicitly) indicate that you can do that.

I welcome such changes but I have almost lost faith in this process where "purity" (with respect
to X500) is given precedence over deployment and current practice.   I would though be very
worried to squeeze in all this in a week or so.  If you go ahead that will delay the process
another 4 weeks at least.  I have no problems whatsoever with that. 

BTW, why not reinstate dnqualifer although it is a little bit redundant as it is already in use?
In principle (sloppy, but this is where we are today) dnq should be used as name disambiguer and
serialnumber as some kind of more or less static indentity versus a naming domain.  Note: this is not
a high-priority issue but why "outlaw" something that has until very recently become suspect?  
I am now talking about son-of-RC2459 rather than just QC.

Anders

Date: Wed, 23 Feb 2000 16:51:50 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Andreas Berger <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: German Law and OCSP

Andreas,

Thank you for attempting to provide some explanations.

> I will try to give some of the rationale behind the design of the German
> Signature Law as I understand it. You have to understand that the
> requirements were (and still are) not laid down in technical term and
> that - of course - there are different interpretations.
> 
> One basic design was the differentiation between the CA and the
> "information service". The CA issues the certificates and the
> information service - an entity that is a distinct organizational unit
> from the CA - revokes them. This can be interpreted as a technical
> realization of a division of duty which probably could have be solved
> with a requirement for the organizational procedures inside a CA.

Up here this is fine. There are two distinct entities, each one
using its own signing key, one for issuing certificates, and another
one for revoking certificates.

What is not said is whether a relying party will trust *directly*
only the CA key or both the CA key and the Revocation Authority key.
It has deep implications, in particular if the CA key is
compromised.

> Once such a division is made technically, it was extended to the idea
> that a certificate should only be valid once it is inserted in the
> information service database.

I do not understand. To be "valid" a certificate does not (even)
have to be published. It may be given back to the user who may
decide to send it to whatever entity he wishes.

> The law mentions the information service at one point:
> 
> Give that a CA ceases to operate, e.g. when being bankrupt or for what
> reason ever, the certificates are still valid (which is true, a
> revocation of the CA key is not necessary) iff the CA finds another
> trusted party that continues the operation of the information service
> and handles revocations. 

It only means that there must be "some way" to indicate which
Revocation Authority will continue to keep track of revocation
information for the already issued certificates from a given CA.
There is no need for a notion of insertion of certificates in a
public database.

> Accept that this is not a technical idea we
> had, it is an idea that the lawmakers had. But I do think that it has
> some truth in it.
> 
> Another point is that the compromise of a CA key may be a very seldom
> event but the potential cost, even with a desaster plan in place (anyone
> heard about one from any CA?) it may be desirable to have simple
> technical fallback position.

For that case, there exists simple fallback solutions that do not
require the use of an "information service database". The whole
Directory model from which X.509 certificates emerged is making the
assumption that there may be a Repository and, when that this
Repository exists, it is not trusted (this is why certificates are
signed by CAs).

> And a last remark to our OCSP extension: We extended basically the "not
> revoked" case to include extension. This should not disturb other
> systems that use the "not revoked" answer in the original CRL based way

The problem is more important than simply adding an additional
status.

Denis

> Andreas
> --
> Keine Zeit haben wir genug!

Date: Wed, 23 Feb 2000 16:18:48 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked], [email-masked]
Subject: Re: Straw Poll: SerialNumber definition

Since the last call period is now open, let us attempt to
(hopefully) solve this issue within that period.

The solution to use the certPolicy OID proposed by Steve would not
work for an automated processing.
The solution proposed by Stefan would work, but I have something
simpler (but less flexible) that could possibly work.

Let is take a look at an old INFORMATIONAL RFC, i.e. RFC 1685
issused in August 1994. Its name is: Writing X.400 O/R Names.

Basically this document *recommends* a sequence for writing
distinguished names for human beings which is:

G=;I=;S=;O=;OU1=;OU2=;P=;A=;C=;

with:

    Given Name                             Given name        G
    Initial                                Initials          I
    Surname                                Surname           S
    Generation Qualifier                   Generation        Q
    Common Name                            Common Name       CN
    Organization                           Organization      O
    Organizational Unit 1                  Org.Unit.1        OU1
    Organizational Unit 2                  Org.Unit.2        OU2
    Organizational Unit 3                  Org.Unit.3        OU3
    Organizational Unit 4                  Org.Unit.4        OU4
    Private Management Domain Name         PRMD              P
    Administration Management Domain Name  ADMD              A
    Country                                Country           C

Suppose that now we introduce the new atribute called
UniqueIdentifier (UI), instead of SerialNumber which is a little bit
confusing.

The idea is that the *relative* placement of the UI in the DN chain
indicates to what it applies. In other words it serves like a
delimiter. Everything on the left of the delimiter has to be used to
make the name unique and permanent, for the given CA. If it comes
first, then it is self-sufficient by itself (e.g. it could be a
social security number or an employee number). In the following
example, it would only apply to G, I and S but not to O.

G=; I=; S=; UI= ; O=;

What do you think ?

Denis

> Guys,
> 
> I may have a nice solution to this debate.
> 
> May I first draw your attention once again to the fact that the solution in
> the qcStatement extension almost have what you ask for in the first place.
> 
> What we have is a predefined statement in QC 03 saying:
> 
>    3.2.5.1 Predefined Statements
> 
>    This profile includes one predefined object identifier (id-qcs-
>    pkixQCSyntax-v1), identifying conformance with syntax and semantics
>    defined in this profile. This Qualified Certificate profile is
>    referred to as version 1.
> 
>       qcStatement-1 QC-STATEMENT ::= { SemanticsInformation IDENTIFIED
>           BY id-qcs-pkixQCSyntax-v1 }
>       --  This statement identifies conformance with syntax and
>       --  semantics defined in this Qualified Certificate profile
>       --  (Version 1). The SemanticsInformation may optionally contain
>       --  additional semantics information as specified.
> 
>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL }
>           (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
>            WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
> 
>       NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
>           GeneralName
> 
> This is a predefined statement dedicated to include information that would
> clarify the actual content in the DN attributes.
> Lets say that we added another optional data element "dnIdentityMask" in the
> samanticsInformation:
> 
>       SemanticsInformation ::= SEQUENCE {
>           semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
>           nameRegistrationAuthorities NameRegistrationAuthorities
>                                                           OPTIONAL
>           dnIdentityMask              DnIdentityMask   OPTIONAL}
> 
>           DnIdentityMask ::= BIT STRING {
>                countryName             (0),
>                commonName              (1),
>                surname                 (2),
>                givenName               (3),
>                pseudonym               (4),
>                serialNumber            (5),
>                organizationName        (6),
>                organizationalUnitName  (7),
>                stateOrProvinceName     (8),
>                localityName            (9),
>                postalAddress          (10)}
> 
> The defined meaning of dnIdentitymask would then be to specify the minimum
> set of attributes needed to obtain a unique identity of the subject, needed
> to identify the subject among all subjects handled by the CA.
> 
> The good side of this solution is that it can be used without any need to
> define a new OID, since the attribute semantics OID is optional.
> 
> This solution could in a nice way satisfy all needs raised in the discussion
> without breaking any current practice or stretch any intended definitions or
> structures.
> 
> I guess that this could be considered as a minor adjustments to be included
> without requiring a new last call period.
> 
> Thoughts, comments?
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Anders Rundgren [mailto:[email-masked]]
> > Sent: Wednesday, February 23, 2000 10:00 AM
> > To: Denis Pinkas; Stephen Kent
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Straw Poll: SerialNumber definition
> >
> >
> > Steve,
> >
> > <snip>
> > >I'm opposed to adding a notion of selective marking of RDNs to
> > >indicate which ones, in concert, really qualify as a DN, remembering
> > >the definition of a DN.  This was the subject of a private message
> > >exchange between Anders and me last week, so I'm happy to share my
> > >thoughts on this topic.
> > >
> > >The notion underlying this proposal seems to be that DNs are
> > >convenient ways to express human readable names, but that in using
> > >them we should abandon all notions of the DIT context from
> > which they
> > >emanated.
> >
> > Not abandon, a DN would still be a DN.  Heritage is of less interest.
> > The solution is a technical way to solve something that is
> > already performed using
> > "local knowledge and manual settings" by a lot of current RP software.
> >
> > > A purer way to address this need would be to define a new
> > >name type under general names (we have a couple of options for this
> > >in GNs), but this would not be backward compatible with
> > existing apps
> > >that already have some ability to parse DNs, but not all forms of
> > >GNs, much less a new form.
> >
> > As compatibility with existing SW is crucial, some purity
> > will have to be sacrificed.
> > For radical changes like GNs it may be better to look on
> > XML-certs but that is another story.
> >
> > <snip>
> >
> > >I think a better approach to the base problem that motivated this
> > >debate is to use an extension that claims to be a unique ID for the
> > >subject, relative to the Issuer.  But, we already have such a value,
> > >in the form of the SubjectUniqueID, if we really want this feature!
> >
> > As Denis nicely points out, the suggested solution allows
> > arbitrary uses
> > of DN attributes including various combinations with serialNumber and
> > lets say organizationUnit.   But for the RP it looks like a
> > singular solution
> > as it just requires a call to the (anticipated) API function
> > "getQCUnmistakableIdenitity()"
> > to get the optional subset of of DN that holds the
> > unmistakable identity.
> > That is what I call GENERIC SOLUTION and is what standards need.
> >
> > SubjectUniqueID is a SPECIAL CASE of no general interest.
> >
> > <snip>
> >
> > >certs contain subject DNs that differ in other attributes?  Well,
> > >since all the other proposals for selective RDN use require some
> > >means of signalling RP software, why not use a cert policy
> > OID?  It's
> > >just as valid a means of signalling this non-standard
> > interpretation,
> > >for the set of RP software that will need to make use of this fact.
> >
> > Unfortunately NON-STANDARD policy OIDs create much more problems than
> > they solve.  I have already elaborated on that in this list.
> >
> > What is missing from the current suggestion is a Naming
> > Domain definition.
> > I can just find two variants: Either the naming domain is
> > marked as internal/CA
> > and does not have to be known outside, or the CA issues
> > certificates to
> > an external naming domain like "registered Citizen of XYZ".
> > The latter should
> > require an officially registered value of some kind to be
> > interoperable among
> > competing CAs,
> >
> > Conclusion: the maintenance and setup of QC RP SW  can be
> > really greatly simplified!
> >
> > OK, it does not solve the actual meaning of OU, CN, and SN
> > etc. but somewhere you
> > have to stop!
> >
> > Anders
> >
> > PS Steve, do you prefer that a solution according to my and
> > Denis lines are
> > taken to PKI-FORUM rather than developed here?  I don't care where as
> > long as it gets done.  DS
> >
> >

Sender: [email-masked]
Date: Wed, 23 Feb 2000 15:59:54 +0100
From: Andreas Berger <[email-masked]>
Organization: GMD SIT.SICA Darmstadt
To: Denis Pinkas <[email-masked]>
CC: Simon Tardell <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: German Law and OCSP

I will try to give some of the rationale behind the design of the German
Signature Law as I understand it. You have to understand that the
requirements were (and still are) not laid down in technical term and
that - of course - there are different interpretations.

One basic design was the differentiation between the CA and the
"information service". The CA issues the certificates and the
information service - an entity that is a distinct organizational unit
from the CA - revokes them. This can be interpreted as a technical
realization of a division of duty which probably could have be solved
with a requirement for the organizational procedures inside a CA.

Once such a division is made technically, it was extended to the idea
that a certificate should only be valid once it is inserted in the
information service database.

The law mentions the information service at one point:

Give that a CA ceases to operate, e.g. when being bankrupt or for what
reason ever, the certificates are still valid (which is true, a
revocation of the CA key is not necessary) iff the CA finds another
trusted party that continues the operation of the information service
and handles revocations. Accept that this is not a technical idea we
had, it is an idea that the lawmakers had. But I do think that it has
some truth in it.

Another point is that the compromise of a CA key may be a very seldom
event but the potential cost, even with a desaster plan in place (anyone
heard about one from any CA?) it may be desirable to have simple
technical fallback position.

And a last remark to our OCSP extension: We extended basically the "not
revoked" case to include extension. This should not disturb other
systems that use the "not revoked" answer in the original CRL based way

Andreas
-- 
Keine Zeit haben wir genug!

Date: Tue, 22 Feb 2000 22:36:58 -0500
To: "william bamberg" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Diffie-Hellman DomainParameters question
Cc: <[email-masked]>

Will:

Two reasons, one political and one technical.

1.  This structure is aligned with the ANSI X9.42 standard.  The banking 
community and the Internet community will be using the same structure.

2.  The value of q is needed to avoid some small subgroup attacks.  See 
draft-ietf-smime-small-subgroup-03.txt.

Russ

At 04:10 PM 02/22/2000 +0000, william bamberg wrote:
>RFC 2459, and the new draft, both specify the DomainParameters to be
>included along with a D-H public key value with the following syntax:
>
>         DomainParameters ::= SEQUENCE {
>               p       INTEGER, -- odd prime, p=jq +1
>               g       INTEGER, -- generator, g
>               q       INTEGER, -- factor of p-1
>               j       INTEGER OPTIONAL, -- subgroup factor
>               validationParms  ValidationParms OPTIONAL }
>
>I'm not a crypto expert, but I understand that the q value is not actually
>essential for doing Diffie-Hellman, and most D-H certificates that I've come
>across seem to omit it. Could anyone explain to me why it's not optional in
>the spec?
>
>Thanks very much
>
>Will
>
>

From: "Stefan Santesson" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 13:28:51 +0100
Importance: Normal

Guys,

I may have a nice solution to this debate.

May I first draw your attention once again to the fact that the solution in
the qcStatement extension almost have what you ask for in the first place.

What we have is a predefined statement in QC 03 saying:

   3.2.5.1 Predefined Statements

   This profile includes one predefined object identifier (id-qcs-
   pkixQCSyntax-v1), identifying conformance with syntax and semantics
   defined in this profile. This Qualified Certificate profile is
   referred to as version 1.

      qcStatement-1 QC-STATEMENT ::= { SemanticsInformation IDENTIFIED
          BY id-qcs-pkixQCSyntax-v1 }
      --  This statement identifies conformance with syntax and
      --  semantics defined in this Qualified Certificate profile
      --  (Version 1). The SemanticsInformation may optionally contain
      --  additional semantics information as specified.

      SemanticsInformation ::= SEQUENCE {
          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
          nameRegistrationAuthorities NameRegistrationAuthorities
                                                          OPTIONAL }
          (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
           WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})

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

This is a predefined statement dedicated to include information that would
clarify the actual content in the DN attributes.
Lets say that we added another optional data element "dnIdentityMask" in the
samanticsInformation:

      SemanticsInformation ::= SEQUENCE {
          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
          nameRegistrationAuthorities NameRegistrationAuthorities
                                                          OPTIONAL
          dnIdentityMask              DnIdentityMask   OPTIONAL}

          DnIdentityMask ::= BIT STRING {
               countryName             (0),
               commonName              (1),
               surname                 (2),
               givenName               (3),
               pseudonym               (4),
               serialNumber            (5),
               organizationName        (6),
               organizationalUnitName  (7),
               stateOrProvinceName     (8),
               localityName            (9),
               postalAddress          (10)}

The defined meaning of dnIdentitymask would then be to specify the minimum
set of attributes needed to obtain a unique identity of the subject, needed
to identify the subject among all subjects handled by the CA.

The good side of this solution is that it can be used without any need to
define a new OID, since the attribute semantics OID is optional.

This solution could in a nice way satisfy all needs raised in the discussion
without breaking any current practice or stretch any intended definitions or
structures.

I guess that this could be considered as a minor adjustments to be included
without requiring a new last call period.

Thoughts, comments?

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2000 10:00 AM
> To: Denis Pinkas; Stephen Kent
> Cc: [email-masked]; [email-masked]
> Subject: Re: Straw Poll: SerialNumber definition
>
>
> Steve,
>
> <snip>
> >I'm opposed to adding a notion of selective marking of RDNs to
> >indicate which ones, in concert, really qualify as a DN, remembering
> >the definition of a DN.  This was the subject of a private message
> >exchange between Anders and me last week, so I'm happy to share my
> >thoughts on this topic.
> >
> >The notion underlying this proposal seems to be that DNs are
> >convenient ways to express human readable names, but that in using
> >them we should abandon all notions of the DIT context from
> which they
> >emanated.
>
> Not abandon, a DN would still be a DN.  Heritage is of less interest.
> The solution is a technical way to solve something that is
> already performed using
> "local knowledge and manual settings" by a lot of current RP software.
>
> > A purer way to address this need would be to define a new
> >name type under general names (we have a couple of options for this
> >in GNs), but this would not be backward compatible with
> existing apps
> >that already have some ability to parse DNs, but not all forms of
> >GNs, much less a new form.
>
> As compatibility with existing SW is crucial, some purity
> will have to be sacrificed.
> For radical changes like GNs it may be better to look on
> XML-certs but that is another story.
>
> <snip>
>
> >I think a better approach to the base problem that motivated this
> >debate is to use an extension that claims to be a unique ID for the
> >subject, relative to the Issuer.  But, we already have such a value,
> >in the form of the SubjectUniqueID, if we really want this feature!
>
> As Denis nicely points out, the suggested solution allows
> arbitrary uses
> of DN attributes including various combinations with serialNumber and
> lets say organizationUnit.   But for the RP it looks like a
> singular solution
> as it just requires a call to the (anticipated) API function
> "getQCUnmistakableIdenitity()"
> to get the optional subset of of DN that holds the
> unmistakable identity.
> That is what I call GENERIC SOLUTION and is what standards need.
>
> SubjectUniqueID is a SPECIAL CASE of no general interest.
>
> <snip>
>
> >certs contain subject DNs that differ in other attributes?  Well,
> >since all the other proposals for selective RDN use require some
> >means of signalling RP software, why not use a cert policy
> OID?  It's
> >just as valid a means of signalling this non-standard
> interpretation,
> >for the set of RP software that will need to make use of this fact.
>
> Unfortunately NON-STANDARD policy OIDs create much more problems than
> they solve.  I have already elaborated on that in this list.
>
> What is missing from the current suggestion is a Naming
> Domain definition.
> I can just find two variants: Either the naming domain is
> marked as internal/CA
> and does not have to be known outside, or the CA issues
> certificates to
> an external naming domain like "registered Citizen of XYZ".
> The latter should
> require an officially registered value of some kind to be
> interoperable among
> competing CAs,
>
> Conclusion: the maintenance and setup of QC RP SW  can be
> really greatly simplified!
>
> OK, it does not solve the actual meaning of OU, CN, and SN
> etc. but somewhere you
> have to stop!
>
> Anders
>
> PS Steve, do you prefer that a solution according to my and
> Denis lines are
> taken to PKI-FORUM rather than developed here?  I don't care where as
> long as it gets done.  DS
>
>

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Wed, 23 Feb 2000 08:59:57 -0000

Steve,

<snip>
>I'm opposed to adding a notion of selective marking of RDNs to 
>indicate which ones, in concert, really qualify as a DN, remembering 
>the definition of a DN.  This was the subject of a private message 
>exchange between Anders and me last week, so I'm happy to share my 
>thoughts on this topic.
>
>The notion underlying this proposal seems to be that DNs are 
>convenient ways to express human readable names, but that in using 
>them we should abandon all notions of the DIT context from which they 
>emanated.

Not abandon, a DN would still be a DN.  Heritage is of less interest.
The solution is a technical way to solve something that is already performed using
"local knowledge and manual settings" by a lot of current RP software.

> A purer way to address this need would be to define a new 
>name type under general names (we have a couple of options for this 
>in GNs), but this would not be backward compatible with existing apps 
>that already have some ability to parse DNs, but not all forms of 
>GNs, much less a new form.

As compatibility with existing SW is crucial, some purity will have to be sacrificed.
For radical changes like GNs it may be better to look on XML-certs but that is another story.

<snip>  

>I think a better approach to the base problem that motivated this 
>debate is to use an extension that claims to be a unique ID for the 
>subject, relative to the Issuer.  But, we already have such a value, 
>in the form of the SubjectUniqueID, if we really want this feature!

As Denis nicely points out, the suggested solution allows arbitrary uses
of DN attributes including various combinations with serialNumber and
lets say organizationUnit.   But for the RP it looks like a singular solution
as it just requires a call to the (anticipated) API function "getQCUnmistakableIdenitity()"
to get the optional subset of of DN that holds the unmistakable identity.
That is what I call GENERIC SOLUTION and is what standards need.

SubjectUniqueID is a SPECIAL CASE of no general interest.

<snip>

>certs contain subject DNs that differ in other attributes?  Well, 
>since all the other proposals for selective RDN use require some 
>means of signalling RP software, why not use a cert policy OID?  It's 
>just as valid a means of signalling this non-standard interpretation, 
>for the set of RP software that will need to make use of this fact.

Unfortunately NON-STANDARD policy OIDs create much more problems than
they solve.  I have already elaborated on that in this list.

What is missing from the current suggestion is a Naming Domain definition.
I can just find two variants: Either the naming domain is marked as internal/CA
and does not have to be known outside, or the CA issues certificates to
an external naming domain like "registered Citizen of XYZ".   The latter should
require an officially registered value of some kind to be interoperable among
competing CAs,

Conclusion: the maintenance and setup of QC RP SW  can be really greatly simplified!

OK, it does not solve the actual meaning of OU, CN, and SN etc. but somewhere you
have to stop!

Anders

PS Steve, do you prefer that a solution according to my and Denis lines are
taken to PKI-FORUM rather than developed here?  I don't care where as
long as it gets done.  DS

Date: Tue, 22 Feb 2000 19:56:52 -0500
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: [email-masked], "[email-masked]" <[email-masked]>

Denis,

>...
>
>In addition to these two extremes (all versus none), there is a
>number of variations where the dnq (DN Qualifier) does not apply to
>all or none, but to *some* of the components of the DN. This would
>solve other concerns raised on that thread.
>
>All concepts could nicely co-exist if we could find a way to say on
>*which* components of the DN the dnq (DN Qualifier) would apply.
>Rather than leaving the interpretation to an (unprocessable)
>Certificate Policy OID, we should define a way to express which
>components of the RDN should be associated with the dnq to make the
>name unmistakable and *permanently* unique.

I'm opposed to adding a notion of selective marking of RDNs to 
indicate which ones, in concert, really qualify as a DN, remembering 
the definition of a DN.  This was the subject of a private message 
exchange between Anders and me last week, so I'm happy to share my 
thoughts on this topic.

The notion underlying this proposal seems to be that DNs are 
convenient ways to express human readable names, but that in using 
them we should abandon all notions of the DIT context from which they 
emanated.  A purer way to address this need would be to define a new 
name type under general names (we have a couple of options for this 
in GNs), but this would not be backward compatible with existing apps 
that already have some ability to parse DNs, but not all forms of 
GNs, much less a new form.  But RFC 2459 already rejects the notion 
of misusing DNs to express other name forms, despite historical 
precedents, e.g., we disparage sticking RCC 822 names or IP addresses 
in DNs (typically in the guise of the common name attribute).  So, if 
we have insisted on using appropriate name forms for these other name 
types, despite possible backward compatibility problems, why should 
we backtrack when it comes to the notion of creating a new form of 
name, i.e., a DN in which only some RDNS are meaningful?

I think a better approach to the base problem that motivated this 
debate is to use an extension that claims to be a unique ID for the 
subject, relative to the Issuer.  But, we already have such a value, 
in the form of the SubjectUniqueID, if we really want this feature!

Finally, I question the assertion that there is a problem to be fixed 
here, at least in the base spec (2459).   With the current plans to 
use serialNumber as a disambiguator everyone agrees that we have 
addressed the first of the two possible uses.  However, if one wants 
to have this value be unique, relative to the Issuer, that seems 
consistent with the definition now proposed, even though it is 
overkill, i.e., it is still a disambiguator.  How should a CA express 
the notion that this RDN uniquely identifies the subject, even if two 
certs contain subject DNs that differ in other attributes?  Well, 
since all the other proposals for selective RDN use require some 
means of signalling RP software, why not use a cert policy OID?  It's 
just as valid a means of signalling this non-standard interpretation, 
for the set of RP software that will need to make use of this fact.

Steve

Date: Tue, 22 Feb 2000 18:43:42 -0500
To: Anders Rundgren <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SEIS:  RE: WG last call for draft-ietf-pkix-qc-o3.txt
Cc: "[email-masked]'" 	 <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Magnus Nystrom'" 	 <[email-masked]>

Anders,

>--- Message on the SEIS mailing list ([email-masked])
>
>Interesting timing of a last call :-)
>

Stefan asked me to initiate the last call 2 weeks ago, but travel and 
forgetfulness on my part delayed the message.

Steve

Date: Tue, 22 Feb 2000 11:49:03 -0800
To: Paul Koning <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Cc: [email-masked], [email-masked]

At 10:43 AM 02/21/2000 -0500, Paul Koning wrote:
> >>>>> "Denis" == Denis Pinkas <[email-masked]> writes:
>
>  Denis> As David Kemp noticed it there are two ways to use additional
>  Denis> RDN attributes:
>
>  Denis> 1) as a disambiguator,
>
>  Denis> Originally the idea was to add a disambiguator only in the
>  Denis> case where two certificates, without the disambiguator, would
>  Denis> contain identical DNs.
>
>  Denis> 2) as a static identifier.
>
>  Denis> Originally the idea was to use the static identifier without
>  Denis> using the other DN components, which meant that the static
>  Denis> identifier was sufficient to identify an individual.
>
>  Denis> The first case means that *all* the components of the DN are
>  Denis> used in conjunction with the dnq (DN Qualifier), while the
>  Denis> second means that *none* of the components of the DN are used
>  Denis> in conjunction with the dnq (DN Qualifier).
>
>  Denis> In addition to these two extremes (all versus none), there is
>  Denis> a number of variations where the dnq (DN Qualifier) does not
>  Denis> apply to all or none, but to *some* of the components of the
>  Denis> DN. This would solve other concerns raised on that thread.
>
>Ouch.
>
>The situation we started from is that there were two ways of
>interpreting a particular attribute.  The new situation you're
>pointing to is to increase that number from 2 to N.  I think that's a
>large step in the wrong direction.
>
>The problem with many standards is that they have too many options,
>not too few.  Adding more stuff for the purpose of adding N-2 new
>options is not a good thing at all, in my view.
>
>         paul

In retrospect, had a value been built-in to the spec, indicating
which subset of DN/RDN attributes constitute "unique-id" from an
issuing CAs perspective, it could be seen as reducing 2 ways to 1.
I.E., ALWAYS rely on the given subset specification.  While this
would make processing mechanical, it would not help in promoting
a "common uniqueness profile" if that is the real concern.

___tony___

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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Diffie-Hellman DomainParameters question
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 23 Feb 2000 07:59:23 (NZDT)

"william bamberg" <[email-masked]> writes:

>I'm not a crypto expert, but I understand that the q value is not actually
>essential for doing Diffie-Hellman, and most D-H certificates that I've come
>across seem to omit it. Could anyone explain to me why it's not optional in
>the spec?

This is required by the particular version of X9.42 which was current when the
RFC 2459 draft was written, <grumble>ignoring the fact that pretty much the 
only thing which uses DH and DH certs is SSL/Skip/etc, which use PKCS #3 
DH</grumble>.

(I was very restrained there, I didn't post the 3-page rant which any mention
 of X9.42 usually triggers :-).

Peter.

From: [email-masked]
To: "[email-masked]'" <[email-masked]>
Date: Tue, 22 Feb 2000 11:54:02 -0500
Subject: unsubscribe

unsubscribe

From: "Mahmood, Mohsin" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: unsubscribe
Date: Tue, 22 Feb 2000 11:33:42 -0500

unsubscribe

-----Original Message-----
From: Meggison, Tim [mailto:[email-masked]]
Sent: Tuesday, February 22, 2000 11:06 AM
To: 'Russ Housley'
Cc: [email-masked]'
Subject: RE: Cert chain validation

If the policy extensions in all the certs are marked non-critical, is it
valid for a Relying Party to ignore the policy extensions during path
validation, but still display any associated User Notices?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, February 22, 2000 10:19 AM
To: Meggison, Tim
Cc: [email-masked]'
Subject: Re: Cert chain validation

Tim:

OIDs are not intended to have any semantics derived from their structure. 
The only appropriate operation is exact-match.  Given this, the chain you 
provide should be considered invalid.

Russ

At 05:36 PM 02/21/2000 -0500, Meggison, Tim wrote:
>Suppose I have a certificate chain consisting of a Root, a CA and a User
>certificate.
>
>The policy extension in the Root certificate contains one oid of 1.2.4.
>The policy extension in the CA certificate contains one oid of 1.2.4.
>The policy extension in the User certificate contains one oid of 1.2.4.1.
>
>Assuming all other data is valid, is this a valid certificate chain?
>
>It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
>would determine that this certificate path is invalid.  And the way to
>correct it would be to add a policy mapping to the CA certificate for the
>oid 1.2.4.1.
>
>Is the policy mapping necessary  in a closed-community, if the Relying
Party
>trusts all certs issued with a policy oid of 1.2.4 and all certs issued
with
>a policy oid of 1.2.4.1?

From: Anders Rundgren <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
Subject: RE: WG last call for draft-ietf-pkix-qc-o3.txt
Date: Tue, 22 Feb 2000 17:19:48 +0100

Interesting timing of a last call :-)

I agree that the things that have been discussed recently are too late to add
without really screwing up the whole project.

I though really lack some rules for a QUALIFIED CA like

DN interpretation/unmistakable identity that should be DECLARED
Naming domain that should be DECLARED
The possibility to compare certs from a certain CA that should be DECLARED

Note: This would not break anything, just improve security, usability and interoperability.

Anders

----------
From:  Stephen Kent [SMTP:[email-masked]]
Sent:  Tuesday, February 22, 2000 04:00
To:  [email-masked]
Subject:  WG last call for draft-ietf-pkix-qc-o3.txt

I am initiating a 2 week last call on the Internet Draft on Qualified 
Certificates, as indicated in the subject line of this message.

I realize that there is some continuing debate on issues of what 
parts of a DN should be considered essential for uniquely identifying 
the Subject of a certificate. However, this is a broader issue, not 
restricted to QCs, and I expect that it will not be resolved quickly. 
Since the QC document have evolved through a series of drafts and the 
editor has made appropriate changes reflecting WG consensus at each 
stage, it is appropriate to initiate last call at this time.

Steve Kent
PKIX WG Co-chair

From: "william bamberg" <[email-masked]>
To: <[email-masked]>
Subject: Diffie-Hellman DomainParameters question
Date: Tue, 22 Feb 2000 16:10:44 -0000

RFC 2459, and the new draft, both specify the DomainParameters to be
included along with a D-H public key value with the following syntax:

        DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

I'm not a crypto expert, but I understand that the q value is not actually
essential for doing Diffie-Hellman, and most D-H certificates that I've come
across seem to omit it. Could anyone explain to me why it's not optional in
the spec?

Thanks very much

Will

From: "Meggison, Tim" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Cert chain validation
Date: Tue, 22 Feb 2000 11:06:14 -0500

If the policy extensions in all the certs are marked non-critical, is it
valid for a Relying Party to ignore the policy extensions during path
validation, but still display any associated User Notices?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, February 22, 2000 10:19 AM
To: Meggison, Tim
Cc: [email-masked]'
Subject: Re: Cert chain validation

Tim:

OIDs are not intended to have any semantics derived from their structure. 
The only appropriate operation is exact-match.  Given this, the chain you 
provide should be considered invalid.

Russ

At 05:36 PM 02/21/2000 -0500, Meggison, Tim wrote:
>Suppose I have a certificate chain consisting of a Root, a CA and a User
>certificate.
>
>The policy extension in the Root certificate contains one oid of 1.2.4.
>The policy extension in the CA certificate contains one oid of 1.2.4.
>The policy extension in the User certificate contains one oid of 1.2.4.1.
>
>Assuming all other data is valid, is this a valid certificate chain?
>
>It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
>would determine that this certificate path is invalid.  And the way to
>correct it would be to add a policy mapping to the CA certificate for the
>oid 1.2.4.1.
>
>Is the policy mapping necessary  in a closed-community, if the Relying
Party
>trusts all certs issued with a policy oid of 1.2.4 and all certs issued
with
>a policy oid of 1.2.4.1?

Date: Tue, 22 Feb 2000 10:19:25 -0500
To: "Meggison, Tim" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Cert chain validation
Cc: "[email-masked]'" <[email-masked]>

Tim:

OIDs are not intended to have any semantics derived from their structure. 
The only appropriate operation is exact-match.  Given this, the chain you 
provide should be considered invalid.

Russ

At 05:36 PM 02/21/2000 -0500, Meggison, Tim wrote:
>Suppose I have a certificate chain consisting of a Root, a CA and a User
>certificate.
>
>The policy extension in the Root certificate contains one oid of 1.2.4.
>The policy extension in the CA certificate contains one oid of 1.2.4.
>The policy extension in the User certificate contains one oid of 1.2.4.1.
>
>Assuming all other data is valid, is this a valid certificate chain?
>
>It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
>would determine that this certificate path is invalid.  And the way to
>correct it would be to add a policy mapping to the CA certificate for the
>oid 1.2.4.1.
>
>Is the policy mapping necessary  in a closed-community, if the Relying Party
>trusts all certs issued with a policy oid of 1.2.4 and all certs issued with
>a policy oid of 1.2.4.1?

From: "Nick Pope" <[email-masked]>
To: "Schwarz, Bernhard" <[email-masked]>, <[email-masked]>
Subject: RE: using more than one public key
Date: Tue, 22 Feb 2000 10:35:03 -0000
Importance: Normal

his was a basic issue which was considered when deveoping the X.509
extensions and the decision was to keep to the rule that one X.509
certificate should have one AND ONLY ONE key.

Nick Pope

> -----Original Message-----
> From: Schwarz, Bernhard [mailto:[email-masked]]
> Sent: 22 February 2000 09:30
> To: [email-masked]
> Subject: using more than one public key
>
>
> Trying to understand draft-ietf-pkix-qc-03.txt, Chapter 4,
> the following question appeared:
> If we have a Qualified Certificate containing more than one
> public key (different key pairs used for different purposes),
> is the strictly pointed out declaration
>    "... The associated private keys must be unique for the
>    subject, and must be maintained under the subject's sole
>    control. ..."
> to be used for each private key, the public key of which is
> provided in this certificate or only for the key(s) especially
> provided for non-repudiation use?
> Can somebody make that clear?
>
> Thank You
> Bernhard Schwarz
>

From: "Schwarz, Bernhard" <[email-masked]>
To: [email-masked]
Subject: using more than one public key
Date: Tue, 22 Feb 2000 10:30:08 +0100

Trying to understand draft-ietf-pkix-qc-03.txt, Chapter 4,
the following question appeared:
If we have a Qualified Certificate containing more than one
public key (different key pairs used for different purposes),
is the strictly pointed out declaration
   "... The associated private keys must be unique for the
   subject, and must be maintained under the subject's sole
   control. ..."
to be used for each private key, the public key of which is
provided in this certificate or only for the key(s) especially
provided for non-repudiation use?
Can somebody make that clear?

Thank You
Bernhard Schwarz

Date: Mon, 21 Feb 2000 21:59:45 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG last call for draft-ietf-pkix-qc-o3.txt

I am initiating a 2 week last call on the Internet Draft on Qualified 
Certificates, as indicated in the subject line of this message.

I realize that there is some continuing debate on issues of what 
parts of a DN should be considered essential for uniquely identifying 
the Subject of a certificate. However, this is a broader issue, not 
restricted to QCs, and I expect that it will not be resolved quickly. 
Since the QC document have evolved through a series of drafts and the 
editor has made appropriate changes reflecting WG consensus at each 
stage, it is appropriate to initiate last call at this time.

Steve Kent
PKIX WG Co-chair

From: "Manger, James H" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Timestamp: 05: LAST CALL - editorial corrections
Date: Tue, 22 Feb 2000 11:16:46 +1100

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

The TimeStampToken is never defined in ASN.1, not even in the ASN.1 module.
Add to 2.4.2 Response Format, above SignedData definition:
	TimeStampToken ::= ContentInfo -- content type is signedData --
Also add this to Appendix D: ASN.1 module, and include ContentInfo in the
IMPORTS section.
I would also rephrase the text description of TimeStampToken.  It
encapsulates a SignedData value, not the other way around.
Replace the paragraph "A TimeStampToken is as follows .. type SignedData" in
2.4.2 with:
	A TimeStampToken value encapsulates a SignedData value [CMS] that
encapsulates a TSTInfo value.

Appendix D: ASN.1 module lists SignedData and ESSCertID in the IMPORTS
section.  Neither of these are used in the ASN.1 module so delete them from
the IMPORTS section.

------_=_NextPart_000_01BF7CCA.1B1C0F48
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF7CCA.1B1C0F48--

From: "Meggison, Tim" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Cert chain validation
Date: Mon, 21 Feb 2000 17:36:34 -0500

Suppose I have a certificate chain consisting of a Root, a CA and a User
certificate.

The policy extension in the Root certificate contains one oid of 1.2.4.
The policy extension in the CA certificate contains one oid of 1.2.4.
The policy extension in the User certificate contains one oid of 1.2.4.1.

Assuming all other data is valid, is this a valid certificate chain?

It appears to me that the algorithm defined in draft-ietf-pkix-new-part1-00
would determine that this certificate path is invalid.  And the way to
correct it would be to add a policy mapping to the CA certificate for the
oid 1.2.4.1.  

Is the policy mapping necessary  in a closed-community, if the Relying Party
trusts all certs issued with a policy oid of 1.2.4 and all certs issued with
a policy oid of 1.2.4.1?

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Paul Koning'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Mon, 21 Feb 2000 17:33:32 +0100

Paul,

>Ouch.

>The situation we started from is that there were two ways of
>interpreting a particular attribute.  The new situation you're
>pointing to is to increase that number from 2 to N.  I think that's a
>large step in the wrong direction.

Actually Denis proposal (which is exactly what I want to achieve with QC++) shows
a possible way to introduce a GENERIC mechanism that can be AUTOMATICALLY
deciphered (up to the level where the unmistakable identity is revealed) by RP software.
It gives N possibilities nut does not complicate RP software any more than any other extension

<snip>

Anders

Date: Mon, 21 Feb 2000 10:43:16 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Straw Poll: SerialNumber definition

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> As David Kemp noticed it there are two ways to use additional
 Denis> RDN attributes:

 Denis> 1) as a disambiguator,

 Denis> Originally the idea was to add a disambiguator only in the
 Denis> case where two certificates, without the disambiguator, would
 Denis> contain identical DNs.

 Denis> 2) as a static identifier.

 Denis> Originally the idea was to use the static identifier without
 Denis> using the other DN components, which meant that the static
 Denis> identifier was sufficient to identify an individual.

 Denis> The first case means that *all* the components of the DN are
 Denis> used in conjunction with the dnq (DN Qualifier), while the
 Denis> second means that *none* of the components of the DN are used
 Denis> in conjunction with the dnq (DN Qualifier).

 Denis> In addition to these two extremes (all versus none), there is
 Denis> a number of variations where the dnq (DN Qualifier) does not
 Denis> apply to all or none, but to *some* of the components of the
 Denis> DN. This would solve other concerns raised on that thread.

Ouch.

The situation we started from is that there were two ways of
interpreting a particular attribute.  The new situation you're
pointing to is to increase that number from 2 to N.  I think that's a
large step in the wrong direction.

The problem with many standards is that they have too many options,
not too few.  Adding more stuff for the purpose of adding N-2 new
options is not a good thing at all, in my view.

	paul

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Feb 2000 13:36:37 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Cc: [email-masked]

> 
> The IETF draft defines the TimeStampToken datatype as a CMS SignedData
> construct, where the TSTInfo structure is wrapped inside the CMS
> structure.  CMS SignedData constructs can be used in two different
> ways, however; as an encapsulation and as an external signature.  The
> encapsulation mode means the data upon which the signature is computed
> is wrapped inside the CMS structure, whereas the external signature
> mode leaves the data external to the CMS structure.  Both modes provide
> equivalent security, both are directly supported and specified within
> the CMS specification [RFC 2630, page 9].
> 
> The ISO proposal is to simply use the CMS construct as an external
> signature rather than as an encapsulation.  The ISO proposal thus
> defines the 'TimeStampToken' data type as follows:
> 
> TimeStampToken ::= SEQUENCE {
>         tspData         TSTInfo,
>         tspSignature    OCTET STRING }
> 
> The CMS SignedData construct used as an external signature is
> DER-encoded in the tspSignature field.  In effect both proposals
> accomplish the same thing; the TSTInfo structure is signed, and the
> signature information is encapsulated in a CMS SignedData construct.

The inconvenience is to have 'yet another structure': I do not see a
real advantage to replace the CMS SignedData with the structure above.
have a CMS document at the top level has several advantadges; you
might use encryption around it you still have a 'document'.

It might be worth to look at the structure for the Digested-Data
content-Type.  

   The following object identifier identifies the digested-data content
   type:

      id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

   The digested-data content type shall have ASN.1 type DigestedData:

      DigestedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithm DigestAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo,
        digest Digest }

      Digest ::= OCTET STRING

and use this in the case when you 'Digest' corresponds to
something defined by a mecanism. 

Have fun.
Peter Sylvester

Date: Mon, 21 Feb 2000 11:34:47 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: pkix <[email-masked]>
CC: xme <[email-masked]>, RussHousley <[email-masked]>
Subject: AC profile

Hi All,

I'currently working on the next version of the AC profile
(which I hope to get to last call after Adelaide). There
were a few issues from Washington that I said I'd bring to
the list before we issue the new I-D:

- Do we need to support chains of ACs? 

I'd say the answer is "no, not in this version". I think its
reasonable to take the position that very few people will 
want this (and even fewer in the near future) so that anyone 
who they can write a new I-D to extend the profile for that 
case. I think this was the sense of the room in Washington.

- What to do about AAControls? 

I'm not so sure what's right here & would like some input 
(if you don't know what this is about, read the section 
and maybe look at the slides from Washington). My preference
today (it changes often:-) is to leave it in pretty much 
as is, but move it to section 7, so that it becomes optional 
to implement.

Other than that, I also need to bring up the recovation
schemes, but I'll wait 'till I've got text that's in 
synch with the latest X.509 DAM before bringing that to
the list.

Regards,
Stephen.

PS: For those of you who've already sent me comments, 
I'm going through them now, so no need to resend.

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Straw Poll: SerialNumber definition
Date: Mon, 21 Feb 2000 11:08:06 +0100

Denis,

<snip>

>All concepts could nicely co-exist if we could find a way to say on
>*which* components of the DN the dnq (DN Qualifier) would apply.
>Rather than leaving the interpretation to an (unprocessable)
>Certificate Policy OID, we should define a way to express which
>components of the RDN should be associated with the dnq to make the
>name unmistakable and *permanently* unique. 

>In this way RPs could use this minimum structure in their ACLs. Note
>that at the same time this would define the rule to compare two
>certificates, i.e. know whether they bear the same minimum permanent
>structure and hence refer to the same individual or not.

This sounds like MUSIC in my ears!

<snip>

Anders

From: [email-masked]
To: [email-masked]
Date: Mon, 21 Feb 2000 11:57:25 +0200
Subject: unsubscribe

unsubscribe

Date: Mon, 21 Feb 2000 10:49:27 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: "[email-masked]" <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition

As David Kemp noticed it there are two ways to use additional RDN
attributes:

1) as a disambiguator,

Originally the idea was to add a disambiguator only in the case
where two certificates, without the disambiguator, would contain
identical DNs.

2) as a static identifier.

Originally the idea was to use the static identifier without using
the other DN components, which meant that the static identifier was
sufficient to identify an individual.

The first case means that *all* the components of the DN are used in
conjunction with the dnq (DN Qualifier), while the second means that
*none* of the components of the DN are used in conjunction with the
dnq (DN Qualifier).

In addition to these two extremes (all versus none), there is a
number of variations where the dnq (DN Qualifier) does not apply to
all or none, but to *some* of the components of the DN. This would
solve other concerns raised on that thread.

All concepts could nicely co-exist if we could find a way to say on
*which* components of the DN the dnq (DN Qualifier) would apply.
Rather than leaving the interpretation to an (unprocessable)
Certificate Policy OID, we should define a way to express which
components of the RDN should be associated with the dnq to make the
name unmistakable and *permanently* unique. 

In this way RPs could use this minimum structure in their ACLs. Note
that at the same time this would define the rule to compare two
certificates, i.e. know whether they bear the same minimum permanent
structure and hence refer to the same individual or not.

Let me make a proposal to explain the idea a little bit more. A DN
is an ordered sequence of RDN Attributes. If we added a new
attribute, it could say which components of the ordered sequence of
RDN Attributes shall be used with the dnq to make the name not only
"unmistakable" bu also permanently unique. This could be, for
example, a bit string. If bit 3 is on, this means that the third
component of the DN has to be used with the dnq to make the whole DN
unmistakable and unique *over time* for a given CA. 

This allows to know how the dnq and other DN components are to be
interpreted during the decoding of the unmistakable identity, in a
fully processable way. The big advantage is that we then have a way
to automatically process names, rather than to rely on unprocessable
Policy OIDs.

Denis

Reply-To: "leili" <[email-masked]>
From: "lilei" <[email-masked]>
To: <[email-masked]>
Subject: unsubscript
Date: Mon, 21 Feb 2000 15:20:23 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_013D_01BF7C7F.2C23D5A0
Content-Type: text/plain;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_013D_01BF7C7F.2C23D5A0
Content-Type: text/html;
	charset="hz-gb-2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3D"text/html; charset=3Dhz-gb-2312" =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_013D_01BF7C7F.2C23D5A0--

Date: Mon, 21 Feb 2000 13:33:35 +0800
From: jinhy <[email-masked]>
To: [email-masked]
Subject: unsubscript

From: [email-masked]
To: [email-masked]
Date: Sun, 20 Feb 2000 22:11:34 -0500
Subject: Re: Straw Poll: SerialNumber definition

     This question may be split into several separate ones.  First, should
there exist standard attributes with the following characteristics: 1)
affiliation ID, typically an employee ID, a membership ID, or a customer
number, assigned by either the organization in the DN containing it or one
of the organizational units in that DN and must be unique at the time of
its assignment (not necessarily for all time); 2) DN Disambiguator, added
to at least one of two otherwise identical DN's by a directory
administrator or a CA for the purpose of breaking an ambiguity; 3) national
ID, which is similar to affiliation ID but assigned by the country in the
DN?  Second, if defined should they be permitted in DN's?  Third, should
any existing standard X.520 attributes be mapped onto any of these three,
which would require some amendments to their definitions in X.520?  Fourth,
for any attributes permitted in DN's, are they permitted to appear in the
same RDN with a CN or Surname attribute?    The suggestions which have been
made which involve "yes" for the third question are that serial number be
interpreted for persons (for which it is currently undefined) as
affiliation ID or national ID above, and that the clause requiring that DN
Qualifier have the same value for all entries in a single DSA be repealed,
and then DN Qualifier be used as one of the three possibilities above.

      I know of no real argument that either affiliation ID or DN
Disambiguator is an inappropriate or undesirable attribute, and the only
question about national ID is whether it is desirable from a privacy
standpoint.  National policy might well ban its use in some countries, and
ban its use as a naming attribute in others.  I am one of those who have
suggested that serial number's definition be amended and that it be used
for affiliation ID.  I also think that any of these attributes should be
permitted in the same RDN as personal name attributes if they are permitted
in names at all.  Some of the responses in this poll have left me unsure as
to how a relying party could tell whether the proposed use of serial number
or DN Qualifier was expected to be unique on a country basis or on an
organization basis.
     There are two further questions which arise if one or both of the ID's
above are defined as attributes or mapped to existing ones.  Should there
be separate attributes for variants of either or both of the ID's above
which imply that the ID is expected to be unique over very long periods of
time (multiple centuries for national ID), so that a DN containing the ID
but no personal name is a long-lived identity?  Also, should affiliation ID
above be further subdivided according to the nature of the affiliation
(employee, member, customer, etc.)?

          Tom Gindin

P.S. The opinions above are mine, and not necessarily those of my employer.

Date: Sun, 20 Feb 2000 15:42:12 -0600
From: Roland Mueller <[email-masked]>
Organization: TUVIT Inc.
To: Denis Pinkas <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

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

Hello Denis,

The ISO working group would like to thank the members of the IETF
working group for their efforts toward producing an interoperable
timestamping standard.  We are pleased to incorporate aspects of the
recent IETF proposal into our work in the interests of developing a
truly interoperable standard.

1. Request message

We concur with the IETF proposal for making the 'mechanism' field of
the interoperable request message an optional field, placed in the
structure at a position selected by the authors of the IETF draft
document.  We feel the selection of a default value for the field is a
matter of local policy and hence should be determined by the local
policy statement of the TSA.

2. Error codes

We concur with the IETF proposal for setting aside a range of error
codes for future use by the SC 27 group.  At this time only one
additional code is anticipated, however setting aside a quantity of
error codes for use by SC 27 is a quite reasonable approach.

3. Reply message

The latest IETF proposal suggests that replies generated by the
systems are quite different, and hence cannot be aligned.  The ISO
working group would respectfully disagree here, as the replies are
actually quite similar, and we believe they can be aligned with a
minimum of effort.

The timestamp information returned by both proposals is actually
identical, as the ISO proposal has chosen to adopt the IETF TSTInfo
structure, with an optional mechanism field corresponding to the one
agreed to above.  Since both proposals use the same TSTInfo structure,
time values are interoperable, hash codes and algorithms are
interoperable, policy and mechanism identifiers are interoperable.
Both proposals encapsulate the TSTInfo structure in the TimeStampToken
datatype; the only remaining difference is in syntax of that datatype.

The IETF draft defines the TimeStampToken datatype as a CMS SignedData
construct, where the TSTInfo structure is wrapped inside the CMS
structure.  CMS SignedData constructs can be used in two different
ways, however; as an encapsulation and as an external signature.  The
encapsulation mode means the data upon which the signature is computed
is wrapped inside the CMS structure, whereas the external signature
mode leaves the data external to the CMS structure.  Both modes provide
equivalent security, both are directly supported and specified within
the CMS specification [RFC 2630, page 9].

The ISO proposal is to simply use the CMS construct as an external
signature rather than as an encapsulation.  The ISO proposal thus
defines the 'TimeStampToken' data type as follows:

TimeStampToken ::= SEQUENCE {
        tspData         TSTInfo,
        tspSignature    OCTET STRING }

The CMS SignedData construct used as an external signature is
DER-encoded in the tspSignature field.  In effect both proposals
accomplish the same thing; the TSTInfo structure is signed, and the
signature information is encapsulated in a CMS SignedData construct.

Defining the TimeStampToken type as proposed above allows both IETF
and ISO mechanisms to generate fully interoperable tokens, while in
addition allows the ISO to develop those additional mechanisms it
has identified for support.

On a final note, aligning the standards as proposed above has the
added benefit of making the token embedding technique detailed in
Annex A of the IETF draft also completely interoperable.  No changes
to that Annex are required.
--------------A23E26B45D5DF83AA08D4D91
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------A23E26B45D5DF83AA08D4D91--

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "PKIX-List" <[email-masked]>
Subject: QC++ BOF suggestion
Date: Sat, 19 Feb 2000 10:23:03 -0000

In spite of the delayed QC draft, Qualified Certificates are in production since quite a while. 

I wonder if there is any sentiment for starting a new QC++ work that is targeted
at future QCs?

Why?
Well, as I hope that has shined through my frequent postings I do not believe that
a draft that contains a huge number of loose ends is suitable for MECHANICAL
digestion by RPs.   The certificate comparision section telling that it must
be performed with "care" is a very notable example of that. 

A prime goal of QC++ is that you must be able to compare certificates and that
different DN components may be assigned precedence in a way that is a de-facto
standard.  QC++ supports these rules within the certificate itself.

QC-03's optional private CP OIDs and QC statements cannot be added to an
existing customer base so they really just makes the process even harder.  I.e. is 
there an CP OID in the cert and if it is not, is that an error etc. etc.

The main target for QC++ are public PKIs and commercial TTPs, but long-term all
QC-issuers will gain from the software framwork that will support this.

Anders Rundgren

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "Charles Moore" <[email-masked]>, <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Sat, 19 Feb 2000 09:24:14 -0000

Charles,

>I can send you some example of CP qualifiers that we have use din closed
>communities to do some of the things you are looking for...

Don't do that because as I say, the number of rules to MANDATORY DECLARE for a QC CA
(in plain writing, NOT as private OIDs) can't be that great.  To solve the "identity crisis" that is.

It could/should be 

   Naming domain
      "Citizen of Guatemala"
      "VeriSign Qualified Certificate Domain"
      "Telia Mobitel"
      "IBM Corp."
      "Utah Driving License Register"

   How subject DNs are to be interpreted to form the unmistakable identity (*)
      "All DN components"
      "[SN only],  CN contains the name of the subject at the time of issuing"
      "[SN + OU], CN contains the name of the subject at the time of issuing"

  How the CA reuses unmistakable identities (UI)
      "Never reuses an UI to another entity"
      "May reuse an UI to another entity"      ; Should NOT be alllowed for a QC IMO

(*) Strictly X.500 all QC-variants using the entire DN form an unmistakable identity
but that the THEORETICAL model.   The PRACTICAL model may go a few steps
further.  And does so in a number of large, potentially very important PKIs.

Anders

From: "Anders Rundgren" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: Re: Straw Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 23:39:37 -0000

Stefan,

<snip>

>Let me give you one reason/example why we can't require serialNumber to be
>unique for a person.

This is very important: I do not REQUIRED that serialNumbers should be unique
for a person.  I really think they should but my world is not smashed into pieces if I don't get
it.  Such a solution would IMO require a reinstated dnQualifier as well.

I have though requested simple (as I am only intereted in real-world stuff you know) additions
to QC CP-requirements so that a conforming CA must DECLARE a few VERY important things like

   Naming domain.

   How serialNumbers and other DN components are to be interpreted during the decoding of the
   unmistakable identity and that this interpretation may or may not be X500-friendly (using DN as a whole).

   State the reuse of the extracted identity over time versus entities.

With a fairly limited set of rules like that you can design apps with confidence and compare certs
or SNs or whatever in a defined way.

To use private OIDs for such things is IMO a vaste of time as you have to do this separately
for each CA as the OIDs are not standardized.  And then there is the default-interpretion-rule-trauma.

Note: No new bits and bytes.  Just rules will do the trick.

<snip>

Anders

From: Charles Moore <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Anders Rundgren <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: SEIS:  Stray Poll: SerialNumber definition
Date: Sat, 19 Feb 2000 07:50:55 +1000

My personal preference was for a new attraibute, but given that serial
number is wrong..., dnq was in a previous draft, and it appears that there
is consensus that your usage of dnq is actually valid....
Then your suggestion seems a resonable way forward...

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Saturday, 19 February 2000 0:04
To: Anders Rundgren; [email-masked]; [email-masked];
[email-masked]
Subject: SEIS: Stray Poll: SerialNumber definition

Reinstate dnQualifier!
It is more "user friendly" when discussing certificate contents with
non-technical people. In 
the wake of the EU-directive this will definitively be the case that a much
larger community 
than PKIX will address digital certificate format and content. Nobody wants
to think of 
themselves as "serial number". Besides, as A. Rudgren points out, the
dnQualifier has been 
(mis)used for unique number by many (us in Norway, e.g.).
Best regards,
Katarina de Brisis
____________________________________________________________________
Katarina de Brisis, senior adviser, Royal Ministry of Labour and Government 
Administration, P.O. Box 8004 Dep., 0030 Oslo
Phone + 47 22 24 46 46 Fax + 47 22 24 95 17
Internet e-mail [email-masked]

From: "Stefan Santesson" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 22:45:50 +0100
Importance: Normal

Anders,

As you may see if you read the specified section 3.2.5.1, there are no
speciffic OID:s for Swedish civic registration number etc, but there is a
defined place to put such OID:s if they are defined within a local
community.

I also would like to point out the solution mentioned by David Kemp, where
you can use a policy OID with a similar effect.

Let me give you one reason/example why we can't require serialNumber to be
unique for a person.

That is the case when the serialNumber contains an employee number or
similar code, which is unique only in combination with the organization
name.

When we have:

CN="Joe Black"
O="IBM"
SN="1234"

and

CN="Joe Black"
O="SUN"
SN="1234"

Well, is this the same person Joe Black working in two different
organizations or is this two persons with the same name and accidently also
having the same employee number.

Well, I sure can't tell and most systems would simply not care. But I'm sure
that our scheme in QC must recognize both cases as valid. Consequently the
exact sematics mut be allowed to be provided by other means (policy OID
and/or qcStatements extension)

/Stefan

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Friday, February 18, 2000 5:23 PM
To: [email-masked]; [email-masked]; 'Stefan Santesson'
Subject: RE: Stray Poll: SerialNumber definition

Stefan,

 >This is all wrong.

>Section 3.2.5.1 gives you all the tools you need to explicitly define the
>nature of the content in the serialNumber attribute.

OK, where can I find the list of defined OIDs expressing how to interpret
serialNumber
in the really impressing number of ways you provide in your posting?

Because, if a CA have to define these by itself and communicate this to all
potential
RPs it is really the CA that is setting the standard.  I don't buy into
that.

Another problem is that the absence of a clear default-interpretation of
serialNumber
semantics.

Nice list though!

/Anders

>And you can do more than just identify that the information is unique per
>user, you can also identify in what manner the information is unique (World
>wide unique, unique per certificate in the issuers domain, unique per
>subject in the issuers domain, unique per subject in the specified country
>etc).

>You can even define exactly the nature of the content (Swedish civic
>registration code, Utah drivers license number, etc...)

>And more to it, you can name the registration authority (Swedish tax
>authority, Utah drivers license registry, etc...)

>All of this you already have in QC 03, what else do you need ?

>/Stefan

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Straw (was Stray) Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 21:01:51 -0000

David,
Straw? Pardon my language :-(

>Automated RPs must have:
>
>1) Domain-specific knowledge required to interpret the name schema,
>   to include the meaning of the SN attribute, if present.
>   RPs aren't usually comparing one cert with another, they are
>   allowing the user who has presented a cert to do something useful.
>   If I am filing a tax return, I must identify myself with something
>   meaningful to the tax collection agency.

I don't disagree.   But there is no requirement on a QC-conformat CA to specify anything
in the CP to aid developers.  Regarding RPs comparing certs:  In the Swedish system you
don't even have to compare certs as it is sufficient to know the subjects SN!  And of course
recongnizing that the issuer is one of the trusted CAs issuing such certificates..

>2) Knowledge that a cert belongs to the RP's recognized domain(s).
>   "Someone" (an industry consortium, a standards body, a government
>   agency, a self-appointed policy authority such as a public CA, etc)
>   has to define what their domain means and register an OID to identify
>   the domain.

That is a possibility but who is handling this registration?  I believe that it is enough
that the CA specifies domain in the CP.  Sort of MINIMUM requirement.

<snip>

>Who originally creates the CP and the naming convention is outside the
>scope of the QC profile.  All that matters is that the CA and the RP
>agree on the meaning of a domain and can mechanically determine that a
>cert belongs to the domain.

Hum, there may be thousands of RPs 'listening' to a certain CA.   This thinking does
not scale.  I.e. this MUST be declared by the CA.  In some way.

>One problem with insisting on two different RDN attributes for
>disambiguator and static identifier is that different RPs (or the
>same RP for different purposes) may treat the identical information
>differently.  If there are two certs:
>
>   cn=Pamela Jones + sn=200
>   cn=Pamela Anderson + sn=200
>
>the SN may well identify a single person, but an RP may wish to maintain
>one set of accounts/privileges/attributes/statistics which are segregated
>by CN, and another set which apply to the person regardless of CN.
>For some purposes the certs refer to two different entities; for other
>purposes they refer to a single entity.
>

I must admit that I don't understand this.  To me it is the CA and not the RP that sets
the policy.  If CA = RP (eating its own crap) there is never any need to carry any kind of
additional information in the cert as such info is extracted from various sources based
on authentication.  In case the RP really needs signed/certified additional information,
ACs or Thin PKI solve this.

Anders

From: Souza Neto <[email-masked]>
To: [email-masked]
Subject: SUBSCRIBE
Date: Fri, 18 Feb 2000 17:00:25 -0200

SUBSCRIBE

Date: Fri, 18 Feb 2000 13:49:31 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Straw (was Stray) Poll: SerialNumber definition
To: [email-masked]
Content-MD5: ioKX6PB0GemJYF7s0PUw/A==

> From: Anders Rundgren <[email-masked]>
> 
> OK, where can I find the list of defined OIDs expressing how to interpret 
serialNumber
> in the really impressing number of ways you provide in your posting?
> 
> Because, if a CA have to define these by itself and communicate this to all 
potential
> RPs it is really the CA that is setting the standard.  I don't buy into that.

Anders,

Automated RPs must have:

1) Domain-specific knowledge required to interpret the name schema,
   to include the meaning of the SN attribute, if present.
   RPs aren't usually comparing one cert with another, they are
   allowing the user who has presented a cert to do something useful.
   If I am filing a tax return, I must identify myself with something
   meaningful to the tax collection agency.

2) Knowledge that a cert belongs to the RP's recognized domain(s).
   "Someone" (an industry consortium, a standards body, a government
   agency, a self-appointed policy authority such as a public CA, etc)
   has to define what their domain means and register an OID to identify
   the domain.  In the simplest case, the OID would go in the Certificate
   Policies extension, not requiring the QC Statements extension.  The CP
   would state that the SN attribute contains a taxpayer ID number, and
   the tax collecting RP would only trust CAs known to follow the CP
   (by populating SN as agreed in certs with that CP OID).

Who originally creates the CP and the naming convention is outside the
scope of the QC profile.  All that matters is that the CA and the RP
agree on the meaning of a domain and can mechanically determine that a
cert belongs to the domain.

One problem with insisting on two different RDN attributes for
disambiguator and static identifier is that different RPs (or the
same RP for different purposes) may treat the identical information
differently.  If there are two certs:

   cn=Pamela Jones + sn=200
   cn=Pamela Anderson + sn=200

the SN may well identify a single person, but an RP may wish to maintain
one set of accounts/privileges/attributes/statistics which are segregated
by CN, and another set which apply to the person regardless of CN.
For some purposes the certs refer to two different entities; for other
purposes they refer to a single entity.

---------------------

Stefan,

I can't tell from section 3.2 which extensions MUST be present in a QC
and which are optional.  For example, "The certificate policies extension
SHALL contain the identifier of at least one certificate policy ...",
but it's not unambiguously clear (to me) that the CP extension SHALL
be present in every QC.

Could the required/optional status of each of the five extensions be
stated in section 3.2?

Dave Kemp

From: Anders Rundgren <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'SEIS-List'" <[email-masked]>
Subject: RE: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 17:24:40 +0100

Denis,

<snip>
>> serialNumber DN Disambiguer usage:
>> 
>>         cn=John Doe, sn=456
>>         cn=John Doe, sn=200
>>         cn=Pamela Anderson, sn=200
>> 
>> Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
>> The three certificates MAY (or may not) denote different persons.

>This seems simple but does not work. :-(  In a DN, some AVAs are
>long term invariants while some others are not. What would be needed
>is to qualify a subset of the AVAs that is an invariant. For
>example, an OU in some cases may change over time and there is no
>wish to re-issue a certificate when the change occurs. So it would
>be nice to keep e.g. cn=John Doe, sn=200, even if the OU has
>changed.

You are referring to a non-real-world problem looking for an X.500 solution.
In the REAL world you use employee IDs (if they are organization-wide) or
you have to issue a new certificate.

<snip>
>> Anticipated ID algorithm: Only SN is used to identify the subject.  

>Ah ! Ah! It seems that we are reinventing the wheel. :-)

>Once upon a time, ... there used to be an X.509 v2 certificate with
>an optional field called: "SubjectUnique Identifier". Its use has
>been deprecated. However what is described here matches with the
>intended usage of that field. 

AFAIK It was deprecated due to BITSTRING syntax and (in a very odd way)
partially replaced by serialNumber.  This is used in huge PKIs as UID.

<snip>

Anders

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 17:23:02 +0100

Stefan,

 >This is all wrong.

>Section 3.2.5.1 gives you all the tools you need to explicitly define the
>nature of the content in the serialNumber attribute.

OK, where can I find the list of defined OIDs expressing how to interpret serialNumber
in the really impressing number of ways you provide in your posting?

Because, if a CA have to define these by itself and communicate this to all potential
RPs it is really the CA that is setting the standard.  I don't buy into that.

Another problem is that the absence of a clear default-interpretation of serialNumber
semantics.

Nice list though!

/Anders

>And you can do more than just identify that the information is unique per
>user, you can also identify in what manner the information is unique (World
>wide unique, unique per certificate in the issuers domain, unique per
>subject in the issuers domain, unique per subject in the specified country
>etc).

>You can even define exactly the nature of the content (Swedish civic
>registration code, Utah drivers license number, etc...)

>And more to it, you can name the registration authority (Swedish tax
>authority, Utah drivers license registry, etc...)

>All of this you already have in QC 03, what else do you need ?

>/Stefan

Date: Fri, 18 Feb 2000 16:59:55 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Anders Rundgren <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'SEIS-List'" <[email-masked]>
Subject: Re: Stray Poll: SerialNumber definition

Anders,

I have followed some of the exchanges.

> Hi,
> The current QC-03 definition of serialNumber is ambiguous.  This
> posting is trying to find out the support for such a solution in a standard-to-be,
> targeting legally binding signatures.  The two uses of serialNumber
> are pictured by the following tables with subject DNs from three different
> certificates coming from a single CA.
> 
> serialNumber DN Disambiguer usage:
> 
>         cn=John Doe, sn=456
>         cn=John Doe, sn=200
>         cn=Pamela Anderson, sn=200
> 
> Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
> The three certificates MAY (or may not) denote different persons.

This seems simple but does not work. :-(  In a DN, some AVAs are
long term invariants while some others are not. What would be needed
is to qualify a subset of the AVAs that is an invariant. For
example, an OU in some cases may change over time and there is no
wish to re-issue a certificate when the change occurs. So it would
be nice to keep e.g. cn=John Doe, sn=200, even if the OU has
changed. We could say that in the CP. However, AFAIK, CP are not
machine processable and we have currently no way to say this. Should
we invent one ? Not sure. See the next argument. 
 
> serialNumber UID usage:
> 
>         cn=John Doe, sn=456
>         cn=John Doe, sn=200
>         cn=Pamela Anderson, sn=200
> 
> Anticipated ID algorithm: Only SN is used to identify the subject.  

Ah ! Ah! It seems that we are reinventing the wheel. :-)

Once upon a time, ... there used to be an X.509 v2 certificate with
an optional field called: "SubjectUnique Identifier". Its use has
been deprecated. However what is described here matches with the
intended usage of that field. 

Why don't we use it, instead of using something else that is not
very well named anyway (serialNumber has always been confusing with
the serialNumber from the certificate itself) ?

The SubjectUniqueIdentifier is mainly useful if the content of the
certificate is used for access control purposes. This fixed size
information can be placed in an ACL. It has to be unique for the
issuing CA, not universally unique.

This field can certainly be useful but must remain optional (all
certificates are not used for access control purposes).

> CN is used a "Friendly Name", "Information" etc.
> The two last certificates denote the same person.  John had a successful transsexual operation :-).
> Huge PKI systems are currently being deployed using this scheme.
> 
> The QC-03 draft does neither specify how serialNumber is to be interpreted, nor specify
> how a CA should could inform an RP about its use of serialNumber.
> 
> The alternatives are
> 
> 1. Keep the current definition

The name is a problem anyway.

> 2. Require that a QC-conformant CPS contains information about DN/SN interpretation as well as DN uniqueness over time.

CPs are not machine processable, so this does not work. However, we
shall continue to mandate the uniqueness of the DN as a whole (or of
the alternate name as a whole).

> 3. Separate these uses by either reinstating dnQualifier or creating a new DN disambiguer attribute

dnQualifier would certainly be a better name, but in the absence of
the knowledge of invariant AVAs, the benefits are minimum. The new
DN disambiguer attribute is in fact the SubjectUniqueIdentifier.

> 4. Other...

Introduce the optional field SubjectUniqueIdentifier and make it
part of QC-04.

Denis

> Anders Rundgren

From: [email-masked]
X400-Received: by mta MHNORWAY in /c=no/admd=telemax/prmd=internet/; Relayed;  18 Feb 2000 15:03:38 +0100
X400-Received: by /c=no/admd=telemax/prmd=internet/; Relayed;  18 Feb 2000 15:03:38 +0100
X400-Received: by /c=no/admd=telemax/prmd=dep/; Relayed; 18 Feb 2000 14:03:31 Z
X400-MTS-Identifier: [/c=no/admd=telemax/prmd=dep/; 11465 00/02/18 15:03]
Content-Identifier: 11465 00/02/18
Content-Return: Prohibited
X400-Content-Type: P2-1988 ( 22 )
Conversion: Allowed
Original-Encoded-Information-Types: IA5-Text
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 18 Feb 2000 14:03:31 Z
To: Anders Rundgren <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: SEIS:  Stray Poll: SerialNumber definition

Reinstate dnQualifier!
It is more "user friendly" when discussing certificate contents with non-technical people. In 
the wake of the EU-directive this will definitively be the case that a much larger community 
than PKIX will address digital certificate format and content. Nobody wants to think of 
themselves as "serial number". Besides, as A. Rudgren points out, the dnQualifier has been 
(mis)used for unique number by many (us in Norway, e.g.).
Best regards,
Katarina de Brisis
____________________________________________________________________
Katarina de Brisis, senior adviser, Royal Ministry of Labour and Government 
Administration, P.O. Box 8004 Dep., 0030 Oslo
Phone + 47 22 24 46 46 Fax + 47 22 24 95 17
Internet e-mail [email-masked]

From: "Stefan Santesson" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 15:55:45 +0100
Importance: Normal

Anders,

>Anders wrote:
>
> The QC-03 draft does neither specify how serialNumber is to
> be interpreted, nor specify
> how a CA should could inform an RP about its use of serialNumber.
>

This is all wrong.

Section 3.2.5.1 gives you all the tools you need to explicitly define the
nature of the content in the serialNumber attribute.

And you can do more than just identify that the information is unique per
user, you can also identify in what manner the information is unique (World
wide unique, unique per certificate in the issuers domain, unique per
subject in the issuers domain, unique per subject in the specified country
etc).

You can even define exactly the nature of the content (Swedish civic
registration code, Utah drivers license number, etc...)

And more to it, you can name the registration authority (Swedish tax
authority, Utah drivers license registry, etc...)

All of this you already have in QC 03, what else do you need ?

/Stefan

From: Anders Rundgren <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'SEIS-List'" <[email-masked]>
Subject: Stray Poll: SerialNumber definition
Date: Fri, 18 Feb 2000 14:20:24 +0100

Hi,
The current QC-03 definition of serialNumber is ambiguous.  This
posting is trying to find out the support for such a solution in a standard-to-be,
targeting legally binding signatures.  The two uses of serialNumber
are pictured by the following tables with subject DNs from three different
certificates coming from a single CA.

serialNumber DN Disambiguer usage:

	cn=John Doe, sn=456
	cn=John Doe, sn=200
	cn=Pamela Anderson, sn=200

Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
The three certificates MAY (or may not) denote different persons.

serialNumber UID usage:

	cn=John Doe, sn=456
	cn=John Doe, sn=200
	cn=Pamela Anderson, sn=200

Anticipated ID algorithm: Only SN is used to identify the subject.  CN is used a "Friendly Name", "Information" etc.
The two last certificates denote the same person.  John had a successful transsexual operation :-).
Huge PKI systems are currently being deployed using this scheme.

The QC-03 draft does neither specify how serialNumber is to be interpreted, nor specify
how a CA should could inform an RP about its use of serialNumber.

The alternatives are

1. Keep the current definition
2. Require that a QC-conformant CPS contains information about DN/SN interpretation as well as DN uniqueness over time.
3. Separate these uses by either reinstating dnQualifier or creating a new DN disambiguer attribute
4. Other...

Anders Rundgren

From: "Manger, James H" <[email-masked]>
To: "'PKIX'" <[email-masked]>
Subject: RE: QC: Identification confusion continues
Date: Fri, 18 Feb 2000 14:39:03 +1100

Charlie,

I am beginning to understand your position as more of the history of dnq is
revealed.  I can even accept your solution - imperfect but usable.  Your
solution does go against X.520's explicitly stated intention for dnq, but
perhaps "intended" does not carry the same weight as "shall" or "must" in a
standard.

If QC does revert to using dnq to disambiguate multiple John Smiths it
should add a paragraph such as:
"X.520 intended dnQualifier to disambiguate entries in different
directories, with the same value used for all entries within a directory.
This intention, which is now deprecated, does not preclude the use of
dnQualifier as defined in this standard."
This paragraph would, at last, document this interpretation of dnq in a
standard.  Future users of the standard (who will not have been privy to
these PKIX discussions, as I was not privy to other committee meetings) will
understand the clash with X.520 (and perhaps question it no more).

P.S. The "reference source" & "basis" for the objection was the 2nd sentence
of the X.520 (1993 & 1997) definition of dnQualifier.  No experience, no
implementations, no legacy systems, no commercial imperatives, no history
(well a little), no compatibility, ...

My motivation was to keep the meaning in attribute types.  I see potential
value in knowing the type of an item and in the arrangement of types
(Att/RDN/DN).  However, this value vanishes if the syntax is used without
the semantics, or at least diminished if the semantics are loosened.  This
motivation impacts dnq in two ways: firstly the much discussed clash with
the "2nd sentence" in X.520 (clash = loosened semantics), secondly the
chance to use dnq to alleviate more important semantic perversions like
VeriSign's misuse of org & org unit.  I hoped dnq could be used to include
issuer information in a subject DN without implying a strong relationship
between the subject and the info (using org implies an "affiliation" between
the two).

The end game: for a computer looking at a DN (& little else) to be able to
understand what it means.

P.S. Where is dnQualifier deprecated (standard/draft/discussion/..)?  Is it
just the "intended use" sentence that is deprecated or the whole attribute?

From: "Robert Rowland" <[email-masked]>
To: <[email-masked]>, "'SEIS-List'" <[email-masked]>
Date: Thu, 17 Feb 2000 09:52:04 -0800
Importance: Normal

unsubscribe

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Cc: "'Magnus Nystrom'" <[email-masked]>
Subject: RE: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 16:44:32 +0100

Stefan,

>he WAP definition fits well in the PKIX QC definition, they just put more
>cnstraints on the usage.

The constraints are such that the existence of a serialNumber is effectively a UID
and there is no need to interpret (to create the unmistakable identity), the other subject
attributes as they are redundant.

Such certificates (with serialNumber) from a particular CA can without hesitation
be compared by a server-based RP.

That is a very clear message to someone doing an application IMO. 

Anders

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Thursday, February 17, 2000 16:04
> To: [email-masked]; 'Stefan Santesson'; 'SEIS-List';
> [email-masked]'
> Cc: 'Magnus Nystrom'
> Subject: RE: Serial number and dnQualifier in QC
>
>
> Stefan,
> Do you really read this list?  Overloaded semantics has been
> questioned by many others!
>
> >Neither is the concept of serial numbers defined and even if
> we all have our
> >own interpretation of what a serial number is, I se no reason, and no
> >possibility, to exactly define the concept of serialNumber
> more than the
> >current QC 03 draft already does.
>
> For a standard that is designed to support legally binding
> signatures and
> INTEROPERABILITY we have then come to the point where we
> apparently need a
> de-facto standard instead, so we know what a serialNumber really is.
> Could someone from VeriSign PLEASE inform us how YOU
> intend to utilize serialNumbers so the world has at least
> SOMETHING to cling to?
>
> Its odd that WAP-forum actually succeeded to specify
> conditions regarding serialNumber
> that absolutely does not fit within the QC-03 draft....
>
> WAP:
>
>      "Certificate-issuing applications including this
> attribute in the subject name of an entity
>      must not reuse the attribute value in certificates
> issued to other entities"
>
> That is definitely NOT applicable to a DN disambiguer
>
> And please inform ETSI that WAP-certs (that may very well be
> used in legally
> demanding situations) have another identity concept.
>
> Anders
>

From: "Stefan Santesson" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>, "'SEIS-List'" <[email-masked]>, <[email-masked]>
Cc: "'Magnus Nystrom'" <[email-masked]>
Subject: RE: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 16:27:30 +0100
Importance: Normal

Anders,

The WAP definition fits well in the PKIX QC definition, they just put more
constraints on the usage.

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Thursday, February 17, 2000 16:04
> To: [email-masked]; 'Stefan Santesson'; 'SEIS-List';
> [email-masked]'
> Cc: 'Magnus Nystrom'
> Subject: RE: Serial number and dnQualifier in QC
>
>
> Stefan,
> Do you really read this list?  Overloaded semantics has been
> questioned by many others!
>
> >Neither is the concept of serial numbers defined and even if
> we all have our
> >own interpretation of what a serial number is, I se no reason, and no
> >possibility, to exactly define the concept of serialNumber
> more than the
> >current QC 03 draft already does.
>
> For a standard that is designed to support legally binding
> signatures and
> INTEROPERABILITY we have then come to the point where we
> apparently need a
> de-facto standard instead, so we know what a serialNumber really is.
> Could someone from VeriSign PLEASE inform us how YOU
> intend to utilize serialNumbers so the world has at least
> SOMETHING to cling to?
>
> Its odd that WAP-forum actually succeeded to specify
> conditions regarding serialNumber
> that absolutely does not fit within the QC-03 draft....
>
> WAP:
>
>      "Certificate-issuing applications including this
> attribute in the subject name of an entity
>      must not reuse the attribute value in certificates
> issued to other entities"
>
> That is definitely NOT applicable to a DN disambiguer
>
> And please inform ETSI that WAP-certs (that may very well be
> used in legally
> demanding situations) have another identity concept.
>
> Anders
>

From: Anders Rundgren <[email-masked]>
To: "'Manger, James H'" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Charles Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: dnQualifier has a bright future?
Date: Thu, 17 Feb 2000 16:05:09 +0100

James,
to overload the semantics of dnQualifier is probably not requested by anybody.

But we have a "situation" where we essentially only have three more or the less
bad alternatives

1. Do as QC-03 and overload serialNumber semantics.  Has so far as I can see
   been rejected already.  Note: serialNumber is still a good UID replacement.

2  "Legalize" the current wide-spread misinterpretation of dnQualifier and deprecate 
   the "true" X520 definition based on the assumption that there is virtually no
   customer-base using it

3. Define a brand new attribute and OID for this purpose (dn disambigiuer)

Personally I think that #2 would be better as it is closer to existing misuse and probably also
have direct software support (known OID)

But, #3 is OK as well although it seems that new attributes cause a lot of worries about
broken software etc.  I am not THAT worried as QCs will require new SW that currently is not
standard anyway (like browser plugins to support signing)..

Anders

From: Anders Rundgren <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Magnus Nystrom'" <[email-masked]>
Subject: RE: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 16:03:30 +0100

Stefan,
Do you really read this list?  Overloaded semantics has been questioned by many others!

>Neither is the concept of serial numbers defined and even if we all have our
>own interpretation of what a serial number is, I se no reason, and no
>possibility, to exactly define the concept of serialNumber more than the
>current QC 03 draft already does.

For a standard that is designed to support legally binding signatures and
INTEROPERABILITY we have then come to the point where we apparently need a
de-facto standard instead, so we know what a serialNumber really is.
Could someone from VeriSign PLEASE inform us how YOU
intend to utilize serialNumbers so the world has at least SOMETHING to cling to?

Its odd that WAP-forum actually succeeded to specify conditions regarding serialNumber
that absolutely does not fit within the QC-03 draft....

WAP:

     "Certificate-issuing applications including this attribute in the subject name of an entity
     must not reuse the attribute value in certificates issued to other entities"

That is definitely NOT applicable to a DN disambiguer

And please inform ETSI that WAP-certs (that may very well be used in legally
demanding situations) have another identity concept.

Anders

From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Subject: Serial number and dnQualifier in QC
Date: Thu, 17 Feb 2000 11:53:56 +0100
Importance: Normal

Gentlemen,

I apologies for not being active in this debate but reading through the last
days of traffic on this subject makes me concerned.

First of all I don't like to do this debate all over again unless there are
some new circumstances that we didn't know about in the last round. And I
havn't found any so far...

We know that the dnQualifier have a defined semantics which is clearly
incompatible with a use as name collision eliminator within a DSA. Add to
this the fact that the concept of DSA is not completely relevant for subject
names in QC.

The fact above is confirmed with many persons that doesn't bother to say so
in this debate.

This leave us with serialNumber, which at this moment is being proposed to
be clarified in ITU X.520 by specifying that it can be used with any
"object" instead of just a "device".

This can be considered as a clarification more than a change, since the word
"device" isn't defined in X.509 anyway.

Neither is the concept of serial numbers defined and even if we all have our
own interpretation of what a serial number is, I se no reason, and no
possibility, to exactly define the concept of serialNumber more than the
current QC 03 draft already does.

For those who want to communicate the exact semantics of the code hold in
the serialNumber attribute, there is a solution by using the predefined
statement for attribute semantics in the qcStatemenets extension. Here you
can specify not only the semantics of the content but also the name
registration authority responsible for the code.

This solution is also proposed as a European standard, which currently is
prepared by ETSI.

It is also my understanding that the ITU editors has been informed by PKIX
through Stephen Kent that this issue is settled within PKIX.

I hope we all can move on from here and live with this.

/Stefan

From: "Philip Luo" <[email-masked]>
To: [email-masked]
Subject: retriveing server cert info from server
Date: Wed, 16 Feb 2000 07:15:05 PST

How would I retrieve Server Cert info from a Server, I do not want to
use a browser.
I want to be able to "scan" a SSL server and view this content and
compare it to a DB.

-feng

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "Luo, Feng (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: retrieving cert info from server
Date: Wed, 16 Feb 2000 10:11:38 -0500

How would I retrieve Server Cert info from a Server,  I do not want to use a
browser. I want to be able to "scan" a SSL server and view this content and
compare it to a DB.

-feng

***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************

From: Anders Rundgren <[email-masked]>
To: "'Manger, James H'" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: dnQualifier has a bright future?
Date: Wed, 16 Feb 2000 09:25:54 +0100

Oops James,
My wording was a little bit reversed.  (-: Of course I understood that Tom meant
that the ITU-conformant definition could better be named DSAInstance.

Regarding dnQualifier I though believe it should keep both name and OID
but get a new wording that is in line with its current (incorrect) use in pretty many
places as indicated by others.  

Anders

----------
From:  Manger, James H [SMTP:[email-masked]]
Sent:  Wednesday, February 16, 2000 09:13
To:  'Anders Rundgren'
Subject:  RE: dnQualifier has a bright future?

Tom did not suggest creating DSAInstance as a replacement for DNQualifier,
he said DSAInstance might have been a better choice of name for the
DNQualifier attribute.

DNDisambiguator would be a better name than DNQualifier for qualities you
want.

> ..it was in QC for 12 months!!..
It has been in X.520 for 12 years (and QC is still a draft).

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, "PKIX-List" <[email-masked]>, "Manger, James H" <[email-masked]>, <[email-masked]>
Subject: dnQualifier has a bright future?
Date: Wed, 16 Feb 2000 07:35:01 -0000

Tom and James,

I guess that these recent findings should eliminate dnQualifier from the list
of subjectAttributes in son-of-RFC2459  as it apparently has nothing to
do with subject attributes.  Right?

I believe though that there is a need for a dnQualifier in the way it was interpreted
by the majority of the PKI community (it was in QC for 12 months!!!).

Tom's suggestion to create a DSAInstance replacement looks real good IMO.

Anders

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Manger, James H <[email-masked]>
Cc: 'Anders Rundgren' <[email-masked]>
Date: Wednesday, February 16, 2000 01:08
Subject: RE: QC: Identification confusion continues

>     I agree that DNQualifier was defined for a completely different
>purpose, but that definition makes it much less useful as a naming
>attribute than a "tiebreaker" would be.  The name DNQualifier, along with
>the first sentence of its definition, has led many people to believe that
>it was intended to distinguish between two DN's which otherwise would have
>the same name - without further restriction on its use.  Given its actual
>definition, the name "DSAInstance" would probably be more illuminating.
>
>          Tom Gindin
>
>"Manger, James H" <[email-masked]> on 02/15/2000
>06:58:06 PM
>
>To:   "'Anders Rundgren'" <[email-masked]>
>cc:   Tom Gindin/Watson/IBM@IBMUS
>Subject:  RE: QC: Identification confusion continues
>
>
>
>X.520's definition of dnQualifier is "virtually useless" for your purposes,
>because it was defined for a completely different purpose.  The fact that
>its definition makes it "illegal to use to break ties between two users
>with
>all other attributes the same" strongly suggests it was not meant for this
>purpose.  Attempts to use it for this purpose give it new semantics.
>dnQualifier then has "multiple semantics without adding any disambiguating
>element", which is precisely your (valid) criticism of QC's use of
>serialNumber.
>

From: "Anders Rundgren" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>, "Stephen Kent" <[email-masked]>, "'Ed Gerck'" <[email-masked]>, <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
Subject: Re: Identification confusion continues
Date: Wed, 16 Feb 2000 06:32:58 -0000

Carlisle,

>I try to make it a personal policy not to mention Entrust products in this
>type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
>make an exception.

thanx!

>The Entrust PKI allows the terminal RDN in a DN to be something like
>"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
>employee id.) may be used to ensure uniqueness in DNs that might otherwise
>clash (due to non-uniqueness of the common name in a large organization).
>Nothing mandated, of course; this is just a possible way of populating the
>DN field.
>
>My understanding is that a number of our customers have chosen to configure
>their DNs in this way.  This actually is current practice in many real
>environments.

I would not say that employee ids has much to do with name clashes.  Employee ids
are in 99.9% of all cases unique identities.  Name independent.  These fit the serial number description
without tweaking the original specification more than replacing device with individual.

I.e. I stay unconvinced that serialNumbers are used as dnQualifiers (which I am pretty sure
that Entrust support as well?)  in the way it was interpreted by most of the PKI community
just some months ago.

But actually this does not matter at all.  What DOES matter is that the ambigious
use of serialNumber in QC is not left in its current UNDEFINED state.

Anders

From: Charles Moore <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>, "'SEIS-List'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: QC: Identification confusion continues
Date: Wed, 16 Feb 2000 15:35:21 +1000

>===== Original Message From Anders Rundgren
<SMTP:[email-masked]> 
=====
>Tom,
>
>Pardon me for bringing this to the list but it is really important
>
>You may be right regarding the uselessness of dnQualifier.  My criticism of

the
>current solution is that QC assigns multiple semantics to serialNumber 
without
>adding any disambiguiting element.  That is IMO an extremely basic 
requirement.

cm> Right on....Lets see what luck you have in this forum...

>
>Actually, this debate was to a large extent initiated by my request for
>supporting
>unique identifiers as I felt that the ambiguous dnQualifier was not
>such a great idea.  And apparently that was in-line with other schemes
>like the Swedish and Finnish ID-card programs.  Now we have got
>an ambiguous serialNumber definition that at least for hands-on guys like
>me looks like no progress at all.
>
>Personally I think "esoteric" X-500 issues (taking in account that 
dnQualifier
>was
>not challenged for several years) are of limited importance for the success

of
>QC, compared to
>elementary issues like how unmistakable identities are to be interpreted by
a
>computerized
>relying party, and how unmistakable identities are to be maintained by CAs 
over
>time.
>None of this is covered by QC-03.
>
>Therefore IMO dnqualifier could without hesitation be interpreted as it
>(apparently) was
>by most people just 3 months ago.

as there are about 400Mil certs in exittance with DNq in the form you
require 
it is interesting to listen to the rastional of why they dont work...
The fact is this argument is one about a companies implementation and
exerting 
this into a standard... Might is right type argument that is more 
commercial/political rather than technical...

My one cents worth.....
An interesting side affect is that the same company is aruing in the ITU
that 
PKIX has already agreed  that serial numebvr is the ONLY solution...
Circles within circles....

And serialNumber be a replacement for the
>defunct X-500 UniqueIdentity.   Then there is a slim chance to actually
state
>some
>almost human-readable rules regarding the interpretation of identity 
information
>as well as certificate comparisons.  W.o. such rules we will continue to
>"stumble in the dark" forever.  Yeah!  Some over-paid PKI-consultants will 
have
>less
>to do but I can live with that...
>
>BTW, if ITU's definition of dnQualifier really is useless, is there
>no chance to make it right some day?

The ITU definitioon is ambiguios, there is no problem to solve ( see above),

the arguments are purley accademic and based on commercial interests...
Something that the ITU has traditionally been nuetral about, but this si not

the case today....

>
>Regards
>Anders
>
>----------
>From:  [email-masked] [SMTP:[email-masked]]
>Sent:  Tuesday, February 15, 2000 00:51
>To:  Anders Rundgren
>Cc:  [email-masked]
>Subject:  Re: QC: Identification confusion continues
>
>     You may remember that this subject was discussed on the PKIX list at
>considerable length during November.  James Manger pointed out that the
>definition of DNQualifier was such that it was illegal to use it to break
>ties between two users with all other attributes the same on the same DSA.
>Your misconception is partly my fault, since I sent you the suggestion to
>use DNQualifier a couple of days before James found the following clause
>("and that its value be the same in a given DSA for all entries to which
>this information has been added") in X.520's definition of DNQualifier.
>IMO, this clause makes DNQualifier virtually useless.
>     There was then a lengthy discussion of serialNumber, and the
>possibility of changing its definition in such a way as to make it useful
>for this purpose, which would at least be backward compatible.  IMHO, the
>only remaining possibilities are 1) to amend serialNumber's definition in
>X.520 and use it for QC's, and 2) to define a new attribute.  I have not,
>however, seen any such amendment of serialNumber's definition in X.520.
>     I don't think that political correctness in the usual sense of the
>term has anything to do with these decisions.  Respect for the wording of
>definitions when they have any ascertainable meaning, even when they
>reflect poor decisions, is what is driving this.
>
>          Tom Gindin

From: Charles Moore <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Carlisle Adams'" <[email-masked]>
Cc: "'Ed Gerck'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Subject: RE: Identification confusion continues
Date: Wed, 16 Feb 2000 15:20:55 +1000

Another data point, we allow dnq in out certifiactes exactly as Entrust do
for 
SN ( I now understand their position in the ITU on this matter)..
Anyway this is in "Root certificates that exist within MSoft and Netscape 
Browers so there are X??Million in existance today...

Just another data point...
We use DNq as it has the right semantics, we also have installations that
use 
serial number but with the right semantic...

Enjoy...

>===== Original Message From Carlisle Adams
<SMTP:[email-masked]> 
=====
>Hi,
>
>I try to make it a personal policy not to mention Entrust products in this
>type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
>make an exception.
>
>The Entrust PKI allows the terminal RDN in a DN to be something like
>"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
>employee id.) may be used to ensure uniqueness in DNs that might otherwise
>clash (due to non-uniqueness of the common name in a large organization).
>Nothing mandated, of course; this is just a possible way of populating the
>DN field.
>
>My understanding is that a number of our customers have chosen to configure
>their DNs in this way.  This actually is current practice in many real
>environments.
>
>I'd be surprised if Entrust was the only product that allowed this but, in
>any case, it's one data point.
>
>Carlisle.
>
>
>> ----------
>> From: 	Anders Rundgren[SMTP:[email-masked]]
>> Sent: 	Monday, February 14, 2000 11:09 AM
>> To: 	Stephen Kent; 'Ed Gerck'; [email-masked]; 'Stefan Santesson';
>> 'Magnus Nystrom'
>> Subject: 	RE: Identification confusion continues
>>
>> Thanx Ed!
>> It would be particularly interesting to know who actually use or intend
to
>> use serialNumber as a
>> name collision eliminator.  I.e. the function of dnQualifier according to
>> ITU...
>>
>> /anders
>>
>>
>> ----------
>> From:  Ed Gerck [SMTP:[email-masked]]
>> Sent:  Monday, February 14, 2000 16:54
>> To:  Stephen Kent
>> Cc:  Anders Rundgren; [email-masked]
>> Subject:  Re: Identification confusion continues
>>
>>
>>
>> >Stephen Kent wrote:
>>
>> >> After extensive debate, folks in the ITU and IETF worlds agreed that
>> >> the syntax of what we needed is best expressed by serialNumbner, not
>> >> DNqualifier, and that a broadening of the definition of the former
>> >> attribute was the best path.  Moreover, we had reports from various
>> >> folks that people in the field had come to the same conclusion and
>> >> were already using serialNumber in this fashion.  So, we are
>> >> legitimizing current practice, and meeting a stated need, without
>> >> introducing a new attribute type.
>>
>> >I may have missed this information in the draft?  Seems to me that it
>> >at least shows why the seemingly most obscure path was the path of
>> >choice, by calling a serialNumber what is not a "serial number".
>>
>> >BTW, could we know what "people in the field had come to the same
>> >conclusion and were already using serialNumber in this fashion" and
>> >also who were the "various folks" that reported on this?  It might be
>> >useful to get back to both sides and see exactly what is being done
>> >ahead of the standards.
>>
>> >Cheers,
>>
>> >Ed Gerck
>>

From: "Pratt, Lisa M" <[email-masked]>
To: "'Luo, Feng (Exchange)'" <[email-masked]>, [email-masked]
Subject: RE: digital signature
Date: Tue, 15 Feb 2000 14:44:20 -0800

I believe this site will provide you with that information.
http://www.mbc.com/ecommerce.html

Regards, Lisa
-----Original Message-----
From: Luo, Feng (Exchange) [mailto:[email-masked]]
Sent: Tuesday, February 15, 2000 2:27 PM
To: [email-masked]
Subject: digital signature

Hi,

I am looking for the information about the digital signature program of all
of states (especially NY, NJ), could some one direct me where I should go?

Thanks in advance,
feng

***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************

From: "Luo, Feng (Exchange)" <[email-masked]>
To: [email-masked]
Subject: digital signature
Date: Tue, 15 Feb 2000 17:27:25 -0500

Hi,

I am looking for the information about the digital signature program of all
of states (especially NY, NJ), could some one direct me where I should go?

Thanks in advance,
feng

***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************

From: Carlisle Adams <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>
Cc: Stephen Kent <[email-masked]>, "'Ed Gerck'" <[email-masked]>, [email-masked], "'Stefan Santesson'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
Subject: RE: Identification confusion continues
Date: Tue, 15 Feb 2000 16:45:04 -0500

Hi,

I try to make it a personal policy not to mention Entrust products in this
type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
make an exception.

The Entrust PKI allows the terminal RDN in a DN to be something like
"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
employee id.) may be used to ensure uniqueness in DNs that might otherwise
clash (due to non-uniqueness of the common name in a large organization).
Nothing mandated, of course; this is just a possible way of populating the
DN field.

My understanding is that a number of our customers have chosen to configure
their DNs in this way.  This actually is current practice in many real
environments.

I'd be surprised if Entrust was the only product that allowed this but, in
any case, it's one data point.

Carlisle.

> ----------
> From: 	Anders Rundgren[SMTP:[email-masked]]
> Sent: 	Monday, February 14, 2000 11:09 AM
> To: 	Stephen Kent; 'Ed Gerck'; [email-masked]; 'Stefan Santesson';
> 'Magnus Nystrom'
> Subject: 	RE: Identification confusion continues
> 
> Thanx Ed!
> It would be particularly interesting to know who actually use or intend to
> use serialNumber as a
> name collision eliminator.  I.e. the function of dnQualifier according to
> ITU...
> 
> /anders
> 
> 
> ----------
> From:  Ed Gerck [SMTP:[email-masked]]
> Sent:  Monday, February 14, 2000 16:54
> To:  Stephen Kent
> Cc:  Anders Rundgren; [email-masked]
> Subject:  Re: Identification confusion continues
> 
> 
> 
> >Stephen Kent wrote:
> 
> >> After extensive debate, folks in the ITU and IETF worlds agreed that
> >> the syntax of what we needed is best expressed by serialNumbner, not
> >> DNqualifier, and that a broadening of the definition of the former
> >> attribute was the best path.  Moreover, we had reports from various
> >> folks that people in the field had come to the same conclusion and
> >> were already using serialNumber in this fashion.  So, we are
> >> legitimizing current practice, and meeting a stated need, without
> >> introducing a new attribute type.
> 
> >I may have missed this information in the draft?  Seems to me that it
> >at least shows why the seemingly most obscure path was the path of
> >choice, by calling a serialNumber what is not a "serial number".
> 
> >BTW, could we know what "people in the field had come to the same
> >conclusion and were already using serialNumber in this fashion" and
> >also who were the "various folks" that reported on this?  It might be
> >useful to get back to both sides and see exactly what is being done
> >ahead of the standards.
> 
> >Cheers,
> 
> >Ed Gerck
> 

From: Santosh Chokhani <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Processing CRLs without Issuing Distribution Points
Date: Tue, 15 Feb 2000 16:09:39 -0500

Russ:

The Annex in X.509 is written with the orientation towards how to validate a
certificate with respect to not being revoked.

That is what you want, I think.

In terms of specifics in the example below, your analysis and conclusions
are correct (as usual).

What the X.509 Annex does is define what other CRLs you may use to validate
the scope of reason code of interest to the application for give cert (A or
B) in your example.

Thus, the title of X.509 Annex is slightly misleading, but its focus is to
determine the validity of a certificate with respect to the revocation
information.  The annex does it in a modular fashion.  Any suggestions in
terms of its accuracy or presentation will be greatly appreciated by me and
the X.509 editor.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, February 15, 2000 3:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Processing CRLs without Issuing Distribution Points

Santosh:

We tried to mate the CRL validation section with the Certificate validation 
section.  We found that it needed to be revised for our purposes.  Also, 
the reasons was not clear (at least to Tim and I).

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}

A certificate user that tries to validate Cert-A should consider the 
intersection of the reasons from the DRLDP and the IDP when processing 
CRL-X.  Thus, processing CRL-X only covers keyCompromise.

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

Russ

At 03:24 PM 02/15/2000 -0500, Santosh Chokhani wrote:
>Russ:
>
>Do you think PKIX needs to go beyond the Annex developed for X.509, which
>now is the normative text?
>
>In other words, why can PKIX not adopt the X.509 CRL processing rules text
>or an abridged version of it?
>
>-----Original Message-----
>From: Russ Housley [mailto:[email-masked]]
>Sent: Tuesday, February 15, 2000 3:22 PM
>To: Sean Mullan; [email-masked]
>Cc: [email-masked]
>Subject: Re: Processing CRLs without Issuing Distribution Points
>
>
>Sean:
>
>The CRL reasons extension determines whether the CRL covers all of the
>certificates or not.  The handling of reasons turns out to be fairly
>complex.  Tim Polk and I spent quite a bit of time at a white board working
>out the details.  The CRL processing section in the soon-to-be-posted
>son-of-rfc2459 will hopefully address this.
>
>Tim:
>
>When ca we expect to see the next Internet-Draft?
>
>Russ
>
>
>At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:
>
> >RFC 2459 does not require that CRLs contain an Issuing
> >Distribution Point extension.
> >
> >Does this mean that a CA may issue *partial* CRLs without
> >including an Issuing Distribution Point Extension?
> >
> >If the answer is yes, it is not possible for a relying party to
> >safely determine if a certificate has not been revoked by inspecting
> >a CRL without an Issuing Distribution Point extension. It cannot
> >assume that a single CRL is an exhaustive list and it also cannot
> >assume a sequence of CRLs when taken as one is an exhaustive list.
> >Therefore a relying party cannot safely determine that the certificate in
> >question has not been revoked.
> >
> >RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
> >CRLs containing revoked CA certs only in the authorityRevocationList
> >attribute, but makes no mention as to whether or not those CRLs should
> >contain an Issuing Distribution Point extension. We claim they must in
> >order for a relying party to be sure that the CRL is a partial CRL
> >containing an exhaustive list of revoked CA certs only.
> >
> >Have there been any partial CRLs deployed w/o Issuing Distribution
> >Point extensions?
> >
> >We think that RFC 2459 should be changed (or made more clear) to make
> >the Issuing Distribution Point extension mandatory for CAs which split
CRLs
> >according to reason codes or user/CA type, and that relying parties
> >should treat CRLs without an Issuing Distribution Point
> >extension as complete (exhaustive) CRLs.
> >
> >--
> >Sean Mullan                     Email: [email-masked]
> >Sun Microsystems Laboratories   Tel:   (781) 442-0926
> >One Network Drive               Fax:   (781) 442-1692
> >Burlington, MA 01803-0902

Date: Tue, 15 Feb 2000 15:59:09 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Processing CRLs without Issuing Distribution Points
Cc: [email-masked], [email-masked], [email-masked]

Santosh:

We tried to mate the CRL validation section with the Certificate validation 
section.  We found that it needed to be revised for our purposes.  Also, 
the reasons was not clear (at least to Tim and I).

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}

A certificate user that tries to validate Cert-A should consider the 
intersection of the reasons from the DRLDP and the IDP when processing 
CRL-X.  Thus, processing CRL-X only covers keyCompromise.

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

Russ

At 03:24 PM 02/15/2000 -0500, Santosh Chokhani wrote:
>Russ:
>
>Do you think PKIX needs to go beyond the Annex developed for X.509, which
>now is the normative text?
>
>In other words, why can PKIX not adopt the X.509 CRL processing rules text
>or an abridged version of it?
>
>-----Original Message-----
>From: Russ Housley [mailto:[email-masked]]
>Sent: Tuesday, February 15, 2000 3:22 PM
>To: Sean Mullan; [email-masked]
>Cc: [email-masked]
>Subject: Re: Processing CRLs without Issuing Distribution Points
>
>
>Sean:
>
>The CRL reasons extension determines whether the CRL covers all of the
>certificates or not.  The handling of reasons turns out to be fairly
>complex.  Tim Polk and I spent quite a bit of time at a white board working
>out the details.  The CRL processing section in the soon-to-be-posted
>son-of-rfc2459 will hopefully address this.
>
>Tim:
>
>When ca we expect to see the next Internet-Draft?
>
>Russ
>
>
>At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:
>
> >RFC 2459 does not require that CRLs contain an Issuing
> >Distribution Point extension.
> >
> >Does this mean that a CA may issue *partial* CRLs without
> >including an Issuing Distribution Point Extension?
> >
> >If the answer is yes, it is not possible for a relying party to
> >safely determine if a certificate has not been revoked by inspecting
> >a CRL without an Issuing Distribution Point extension. It cannot
> >assume that a single CRL is an exhaustive list and it also cannot
> >assume a sequence of CRLs when taken as one is an exhaustive list.
> >Therefore a relying party cannot safely determine that the certificate in
> >question has not been revoked.
> >
> >RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
> >CRLs containing revoked CA certs only in the authorityRevocationList
> >attribute, but makes no mention as to whether or not those CRLs should
> >contain an Issuing Distribution Point extension. We claim they must in
> >order for a relying party to be sure that the CRL is a partial CRL
> >containing an exhaustive list of revoked CA certs only.
> >
> >Have there been any partial CRLs deployed w/o Issuing Distribution
> >Point extensions?
> >
> >We think that RFC 2459 should be changed (or made more clear) to make
> >the Issuing Distribution Point extension mandatory for CAs which split CRLs
> >according to reason codes or user/CA type, and that relying parties
> >should treat CRLs without an Issuing Distribution Point
> >extension as complete (exhaustive) CRLs.
> >
> >--
> >Sean Mullan                     Email: [email-masked]
> >Sun Microsystems Laboratories   Tel:   (781) 442-0926
> >One Network Drive               Fax:   (781) 442-1692
> >Burlington, MA 01803-0902

From: Santosh Chokhani <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Sean Mullan <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Processing CRLs without Issuing Distribution Points
Date: Tue, 15 Feb 2000 15:24:37 -0500

Russ:

Do you think PKIX needs to go beyond the Annex developed for X.509, which
now is the normative text?

In other words, why can PKIX not adopt the X.509 CRL processing rules text
or an abridged version of it?

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, February 15, 2000 3:22 PM
To: Sean Mullan; [email-masked]
Cc: [email-masked]
Subject: Re: Processing CRLs without Issuing Distribution Points

Sean:

The CRL reasons extension determines whether the CRL covers all of the 
certificates or not.  The handling of reasons turns out to be fairly 
complex.  Tim Polk and I spent quite a bit of time at a white board working 
out the details.  The CRL processing section in the soon-to-be-posted 
son-of-rfc2459 will hopefully address this.

Tim:

When ca we expect to see the next Internet-Draft?

Russ

At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:

>RFC 2459 does not require that CRLs contain an Issuing
>Distribution Point extension.
>
>Does this mean that a CA may issue *partial* CRLs without
>including an Issuing Distribution Point Extension?
>
>If the answer is yes, it is not possible for a relying party to
>safely determine if a certificate has not been revoked by inspecting
>a CRL without an Issuing Distribution Point extension. It cannot
>assume that a single CRL is an exhaustive list and it also cannot
>assume a sequence of CRLs when taken as one is an exhaustive list.
>Therefore a relying party cannot safely determine that the certificate in
>question has not been revoked.
>
>RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
>CRLs containing revoked CA certs only in the authorityRevocationList
>attribute, but makes no mention as to whether or not those CRLs should
>contain an Issuing Distribution Point extension. We claim they must in
>order for a relying party to be sure that the CRL is a partial CRL
>containing an exhaustive list of revoked CA certs only.
>
>Have there been any partial CRLs deployed w/o Issuing Distribution
>Point extensions?
>
>We think that RFC 2459 should be changed (or made more clear) to make
>the Issuing Distribution Point extension mandatory for CAs which split CRLs
>according to reason codes or user/CA type, and that relying parties
>should treat CRLs without an Issuing Distribution Point
>extension as complete (exhaustive) CRLs.
>
>--
>Sean Mullan                     Email: [email-masked]
>Sun Microsystems Laboratories   Tel:   (781) 442-0926
>One Network Drive               Fax:   (781) 442-1692
>Burlington, MA 01803-0902

Date: Tue, 15 Feb 2000 15:21:49 -0500
To: Sean Mullan <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Processing CRLs without Issuing Distribution Points
Cc: [email-masked]

Sean:

The CRL reasons extension determines whether the CRL covers all of the 
certificates or not.  The handling of reasons turns out to be fairly 
complex.  Tim Polk and I spent quite a bit of time at a white board working 
out the details.  The CRL processing section in the soon-to-be-posted 
son-of-rfc2459 will hopefully address this.

Tim:

When ca we expect to see the next Internet-Draft?

Russ

At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:

>RFC 2459 does not require that CRLs contain an Issuing
>Distribution Point extension.
>
>Does this mean that a CA may issue *partial* CRLs without
>including an Issuing Distribution Point Extension?
>
>If the answer is yes, it is not possible for a relying party to
>safely determine if a certificate has not been revoked by inspecting
>a CRL without an Issuing Distribution Point extension. It cannot
>assume that a single CRL is an exhaustive list and it also cannot
>assume a sequence of CRLs when taken as one is an exhaustive list.
>Therefore a relying party cannot safely determine that the certificate in
>question has not been revoked.
>
>RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
>CRLs containing revoked CA certs only in the authorityRevocationList
>attribute, but makes no mention as to whether or not those CRLs should
>contain an Issuing Distribution Point extension. We claim they must in
>order for a relying party to be sure that the CRL is a partial CRL
>containing an exhaustive list of revoked CA certs only.
>
>Have there been any partial CRLs deployed w/o Issuing Distribution
>Point extensions?
>
>We think that RFC 2459 should be changed (or made more clear) to make
>the Issuing Distribution Point extension mandatory for CAs which split CRLs
>according to reason codes or user/CA type, and that relying parties
>should treat CRLs without an Issuing Distribution Point
>extension as complete (exhaustive) CRLs.
>
>--
>Sean Mullan                     Email: [email-masked]
>Sun Microsystems Laboratories   Tel:   (781) 442-0926
>One Network Drive               Fax:   (781) 442-1692
>Burlington, MA 01803-0902

From: Anne Anderson <[email-masked]>
Date: Tue, 15 Feb 2000 14:36:44 -0500 (EST)
To: [email-masked]
Subject: excluding all distinguished names in NameConstraints

If I want to create a certificate that will not allow the Subject to
issue valid certificates for non-null CertificateSubjectNames or for
SubjectAlternativeNames of type directoryName (ASN.1 "Name"), what
should be in the NameConstraintsExtension?

If I create an excluded GeneralSubtrees containing a name of type
directoryName, then the name must encompass all directoryNames, and
I don't see how that is possible.  An ASN.1 Name is a "SEQUENCE OF"
(i.e. at least 1) RelativeDistinguishedName, so I would have to
specify at least one RelativeDistinguishedName.  That means
specifying at least one AttributeType.  I have now excluded all
DistinguishedNames of that type, but have not excluded others.

If I create a permitted GeneralSubtrees containing no names of type
directoryName, then by definition all names of type directoryName
are permitted unless they are specifically excluded.  If I try to
specify a permitted directoryName GeneralSubtrees, then it must
contain at least one RDN containing at least one AttributeType, so
that directoryName type will be permitted.

The only solution I can see is to define a bogus AttributeType and
create a permitted GeneralSubtrees containing a directoryName
containing that AttributeType.

Is there a better way?  For all GeneralName types, it is possible to
create a name with the correct type but an empty value since they
are strings or SEQUENCE (not SEQUENCE OF).

Anne
-- 
Anne H. Anderson             Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: QC: Unmistakable identity life-span
Date: Tue, 15 Feb 2000 19:44:22 -0000

Sorry for clogging the line but here I have another QC-related issue:

I believe that there should be a requirement on a QC-conformant CA to
never reuse an unmistakable identity to another entity.  

Note that this requirement is completely independent from the unique
static identity issue.

Anders

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Cert comparison needs AI?
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 16 Feb 2000 04:56:40 (NZDT)

Alfred Arsenault <[email-masked]> quoted Anders Rundgren:

>(*) Lotus Notes do not accept any X509 certificates except its own according
>to a recent study by Swedish Police Authorities

Is this for v4 or v5?  Given that v5 does S/MIME (or claims to, I've never 
used it), it'd be impressive if they could do that without handling anyone 
elses certificates.

[As a side-note, given Sweden's discovery (three years after everyone else 
 knew about it :-) of Notes' differential-workfactor crypto, I'm surprised 
 they're still using it at all]

Peter.

Sender: [email-masked]
Date: Tue, 15 Feb 2000 14:44:05 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Comune di Modena
To: Marc Jadoul <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).

This is a cryptographically signed message in MIME format.

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

Marc Jadoul wrote:

> Ok, but may be there is a solution (that i never tried and it might be
> uncompatible with lot of existing software.) :
> 
> If i understand well, you do not want to have your CA keys online for
> security reason ? Or more precisely, you do not want to have some key
> online, because this key is able to sign certificates which would be
> verified by the CA certificate you published ... ?

Unfortunately the only way to be SURE the key is secure from net-attacks
is to unplug the CA... (actually...).
 
> But if you generate a second key for your CA, and use this key ONLY for
> signing CRL, you can achieve what you want.
> 
> Of course you need to sign a CA certificate for this new key. This
> certificate would be signed by your main (old) CA key, but you would use
> a keyUsage extension with only the crlSign bit set. Thus this
> certificate can not be used to verify certificates but can be used to
> verify CRLs.
> 
> It would be reasonably safe to have the second CA key online. At least
> it is as safe as what you can get with online signing of revocation
> status.
> 
> Note that you probably also need the keyid extension also to help
> software to find the good CA certificate.
> 
> Let me know if you think it is possible in real life.
> 
> Marc

I am interested in developing a CA that currently available software will
support. Many sent in the proposal to have a second key-pair on-line
for CRL signing. However, my question is: do current browsers support this
feature ??? Will them correctly import the CRLs signed and verify certificates
against it ??? Does anyone have tried so far such an approach to the problem?

C'you,

	Massimiliano Pala ([email-masked])
--------------ms15C184AFAE44C05F24CC7D0F
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

--------------ms15C184AFAE44C05F24CC7D0F--

From: Alfred Arsenault <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'J D Brooks'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Cert comparison needs AI?
Date: Tue, 15 Feb 2000 08:27:38 -0500

<Anders Rundgren wrote:>

<snip>

IMO QC-03 guarantees that the limited interoperability offered by current
PKI solutions (*) is preserved.

(*) Lotus Notes do not accept any X509 certificates except its own according
to a recent
study by Swedish Police Authorities

(*) Win2K kerberos authentication only accepts its own X509 certificates
according to
a well-known PKI evangelist in another mailing list

Anders

AWA:  It's a bit harsh to blame these things on the QC draft.  If vendors
want their applications to only accept certain certificates and to reject
certificates issued by "competitors" or "those who haven't signed the right
'partnering agreement'", there's nothing we're going to do about it in PKIX.
That's a market-driven issue, and it will always be possible for application
developers to make this so.

			Al Arsenault

-- As usual, my own opinions; may or may not resemble anything my employer
is doing; etc.

From: Anders Rundgren <[email-masked]>
To: "'J D Brooks'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  RE: Cert comparison needs AI?
Date: Tue, 15 Feb 2000 14:05:12 +0100

J D,

>But isn't it the responsibility of the certificate issuing authority to
>ensure two qualified certificates never refer to the same physical entity?

It definitely should, but apparently the concept of unmistakable identity has different
meaning to different people.  As unmistakable identity is the core of Qualified Certificates
it is really sad that so little has been done to penetrate this area.

IMO QC-03 guarantees that the limited interoperability offered by current PKI solutions (*) is preserved.

(*) Lotus Notes do not accept any X509 certificates except its own according to a recent
study by Swedish Police Authorities

(*) Win2K kerberos authentication only accepts its own X509 certificates according to
a well-known PKI evangelist in another mailing list

Anders

From: Anders Rundgren <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'SEIS-List'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: QC: Identification confusion continues
Date: Tue, 15 Feb 2000 11:22:49 +0100

Tom,

Pardon me for bringing this to the list but it is really important

You may be right regarding the uselessness of dnQualifier.  My criticism of the
current solution is that QC assigns multiple semantics to serialNumber without
adding any disambiguiting element.  That is IMO an extremely basic requirement.

Actually, this debate was to a large extent initiated by my request for supporting
unique identifiers as I felt that the ambiguous dnQualifier was not
such a great idea.  And apparently that was in-line with other schemes
like the Swedish and Finnish ID-card programs.  Now we have got
an ambiguous serialNumber definition that at least for hands-on guys like
me looks like no progress at all.

Personally I think "esoteric" X-500 issues (taking in account that dnQualifier was
not challenged for several years) are of limited importance for the success of QC, compared to
elementary issues like how unmistakable identities are to be interpreted by a computerized
relying party, and how unmistakable identities are to be maintained by CAs over time.
None of this is covered by QC-03.

Therefore IMO dnqualifier could without hesitation be interpreted as it (apparently) was
by most people just 3 months ago.  And serialNumber be a replacement for the
defunct X-500 UniqueIdentity.   Then there is a slim chance to actually state some
almost human-readable rules regarding the interpretation of identity information
as well as certificate comparisons.  W.o. such rules we will continue to
"stumble in the dark" forever.  Yeah!  Some over-paid PKI-consultants will have less
to do but I can live with that...

BTW, if ITU's definition of dnQualifier really is useless, is there
no chance to make it right some day?

Regards
Anders

----------
From:  [email-masked] [SMTP:[email-masked]]
Sent:  Tuesday, February 15, 2000 00:51
To:  Anders Rundgren
Cc:  [email-masked]
Subject:  Re: QC: Identification confusion continues

     You may remember that this subject was discussed on the PKIX list at
considerable length during November.  James Manger pointed out that the
definition of DNQualifier was such that it was illegal to use it to break
ties between two users with all other attributes the same on the same DSA.
Your misconception is partly my fault, since I sent you the suggestion to
use DNQualifier a couple of days before James found the following clause
("and that its value be the same in a given DSA for all entries to which
this information has been added") in X.520's definition of DNQualifier.
IMO, this clause makes DNQualifier virtually useless.
     There was then a lengthy discussion of serialNumber, and the
possibility of changing its definition in such a way as to make it useful
for this purpose, which would at least be backward compatible.  IMHO, the
only remaining possibilities are 1) to amend serialNumber's definition in
X.520 and use it for QC's, and 2) to define a new attribute.  I have not,
however, seen any such amendment of serialNumber's definition in X.520.
     I don't think that political correctness in the usual sense of the
term has anything to do with these decisions.  Respect for the wording of
definitions when they have any ascertainable meaning, even when they
reflect poor decisions, is what is driving this.

          Tom Gindin

Date: Mon, 14 Feb 2000 16:32:13 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Implementation of DN vs. SubjAltName Field

Murray,

There has been some very interesting discussion along those lines 
on the SMIME list recently.

It has been pointed out that e-mail addresses may be an invitation to 
spamming, and that it is all too easy to forge the apparent From address
of an e-mail message if only the addr-spec portion of an RFC822 name
is matched.

In addition, as you are recognizing, it can be very difficult to get directory 
administrators to modify their directory structure, even in a fairly small 
organization. Trying to get say the US Navy to change their directory 
structure would be a mind-boggling effort.  Using the RFC822 address
as the primary key field, i.e., primary DN, would result in a very flat directory 
structure that might be hard to maintain.

A third issue is that neither ordinary directory names (as usually deployed)
nor RFC822 names are particularly meaningful or use friendly.

A fourth issue is that none of the name forms provide long term stability
across name changes, organizational changes, etc.

For long term planning, I would suggest that you consider using a constant
employeeID as the linkage between your two DIT structures, whether or not
you include this attribute in the certificate.

Then I would suggest using at least three name forms in your certificates.
the first, which I would like to see used as the primary display form for
the Signer (replacing the From address on a message banner, would be
a subjectAltName in directoryName format containing at a minimum a "real"
commonName, and not some imposed mailbox name.

The second, optional attribute displayed would be the RFC822 name, 
if present, and the third would be the DN in the certificate, which would 
match the DN in the directory.

My advice would be to not make too much of an issue about reissuing 
certificates. Certificates are going to expire in any case, and they should not 
be that expensive or hard to reissue -- if they are, you need to find a different 
CA or CA toolkit vendor, especially since it sounds like you are doing all of 
the due diligence in any case.

Regards,

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally signed, and/or if certificates are attached, the intended purpose is to 
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document to represent any type or form of legally binding contract or other representation, and any such interpretation should not be considered commercially reasonable and WILL BE REPUDIATED, notwithstanding any wording or implications to the opposite effect in the text of the message itself; due in part, but not exclusively, to the fact that the security of my workstation and its associated cryptography is not judged adequately strong for such purposes at present.

>>> "Yutzy, Murray" <[email-masked]> 02/14/00 02:47PM >>>
We are attempting to accommodate a migration from a PKI that will initially
start with a dedicated PKI directory structure to a corporate directory
structure with different DIT's.  A view is to utilize the SubjAltNAme field
with the email as the unique identifier . This would then be the key field
to populate the corporate DS when that time comes. My understanding is that
if you use a DN in the Subject Field, a change in DIT would require
reissuance of the certificate.

Any pointers to additonal information to better understand how applications
utilize the Subject Field for obtaining information about the certificate
would be appreciated.

Murray Yutzy
Lockheed Martin
407/306-1917
Orlando,FL

Date: Mon, 14 Feb 2000 15:21:08 -0800 (PST)
From: J D Brooks <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Cert comparison needs AI?

On Mon, 14 Feb 2000, David P. Kemp wrote:
<ed>
> 
> 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."
> 

But isn't it the responsibility of the certificate issuing authority to
ensure two qualified certificates never refer to the same physical entity?

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: Re: SEIS:  RE: Cert comparison needs AI?
Date: Mon, 14 Feb 2000 23:16:41 -0000

David,

>"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:

I have never said it does not fit the definition, I just dislike the idea to overload the semantics
of serialNumber with the semantics of dnQualifier and not having any defined way in the certificate
to specify which semantic the certificate is actually using.

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

I would say that the QC sample is an example of a certificate that
could generate incorrect results as it seems that a QC-conforming
CA could issue certificates for a person with a certain name and later
(maybe after the person is dead or removed from the files)
issue a certificate for a person with identical name, etc.

CONCLUSION: If QCs can be compared or not is an IMPORTANT (as it is
performed right now in many pre-QC systems using unique identifiers)
QC property that either is a part of the CPS or (even better), becomes
a property of the QC itself.

Anders

Content-return: allowed
Date: Mon, 14 Feb 2000 16:47:16 -0500
From: "Yutzy, Murray" <[email-masked]>
Subject: Implementation of DN vs. SubjAltName Field
To: [email-masked]

We are attempting to accommodate a migration from a PKI that will initially
start with a dedicated PKI directory structure to a corporate directory
structure with different DIT's.  A view is to utilize the SubjAltNAme field
with the email as the unique identifier . This would then be the key field
to populate the corporate DS when that time comes. My understanding is that
if you use a DN in the Subject Field, a change in DIT would require
reissuance of the certificate.

Any pointers to additonal information to better understand how applications
utilize the Subject Field for obtaining information about the certificate
would be appreciated.

Murray Yutzy
Lockheed Martin
407/306-1917
Orlando,FL

From: Anne Anderson <[email-masked]>
Date: Mon, 14 Feb 2000 16:22:54 -0500 (EST)
To: "David P. Kemp" <[email-masked]>, "Peter Gutmann" <[email-masked]>
Cc: [email-masked]
Subject: Re: Recommended change to Unique Identifier handling

Peter Gutman writes:
 > Given that no major[0] CA has ever used UID's, is this really an issue?  I 
 > assume (based on the above message) that someone somewhere is currently using 
 > them despite their having been deprecated for some time, but is it the job of 
 > PKIX to accomodate out-of-spec implementations?

In that case, why not just say: if certificate contains a SubjectUID
or IssuerUID, reject the certificate.  I'm assuming there was some
reason for addressing handling of UIDs in PKIX Part 1, and I am
trying to make such handling consistent and interoperable between
compliant and non-compliant CAs.

David P. Kemp writes:
 > In your example, CA2 has a SubjectUID=null, but it issues a cert to EE1
 > with IssuerUID=CA2-UID.  What is the motivation for CA2 to create such
 > an unorthodox cert?

CA2 may not even know that CA1 has issued a certificate for it (it
may be a cross-certificate).  CA2 may have a self-cert that does
have a SubjectUID in it, and it used that as a base when issuing the
certificate for EE1:

  Trust Anchor 2: Issuer:  CA2
                  Subject: CA2
                  IssuerUID:  CA2-UID
                  SubjectUID: CA2-UID

 > Comments interspersed below ...
 > > b) Assuming a CA is willing to stray from the recommendation in the
 > >    interests of interoperability, then each time the CA signs a CA
 > >    certificate, it MUST know the Issuer Unique Identifier value that
 > >    the subject will store in certificates it generates, and must set
 > >    that value in the certificate's Subject Unique Identifier field.
 > >    Yet the subject may become PKIX-compliant and cease issuing
 > >    certificates with Issuer Unique Identifier values at any time.
 > 
 > In your example of CA1=anchor, CA2, and EE1:  when CA1 signs a
 > certificate for CA2, CA1 MUST know the Issuer UID that CA2 will store
 > in certificates it generates.  That's one way of looking at it, but
 > it seems to reverse cause and effect.  I would look at the situation
 > as:
 > 
 >  1) CA1 issues a cert to CA2 containing a null or non-null SubjectUID.
 >  2) CA2 uses its own SubjectUID as the IssuerUID in all EE certs it issues.
 > 
 > If CA2 wants to become PKIX-compliant and stop issuing UID certs, it
 > can request two certs from CA1 - one with SubjectUID populated to use
 > before the transition, and one with SubjectUID null to use afterwards.
 > Might as well rollover CA2's keypair at the same time, just to make it
 > obvious which EE certs belong in which path.

This would work, although it requires CA2 to know that CA1 is
issuing certificates for it, and it requires CA1 to keep track of
the extra certificate.

 > > c) Again, in the interests of interoperability, each time a CA signs
 > >    a certificate, it MUST know the Subject Unique Identifier stored
 > >    in any certificates that other CAs have signed for itself, and
 > >    MUST use that Subject Unique Identifier as the Issuer Unique
 > >    Identifier in ALL certificates it signs. Since Subject Unique
 > >    Identifier values are completely arbitrary, they may vary across
 > >    different CAs that create certificates for the same principal.
 > >    This creates an impossible situation.
 > 
 > If CA1, CAx, and CAy all issue certs to CA2 with different SubjectUIDs
 > (or different public keys or different Subject names), you have an
 > impossible situation.  UID is not unique in this respect - the issuers
 > simply can't be completely arbitrary in what they say about CA2 and
 > still expect paths to CA2's preexisting EEs to validate.

Point taken.

 > I don't think any change to PKIX UID processing rules is necessary.
 > Assuming that there are currently any CAs which use UIDs, if the CAs
 > can't manage themselves to transition from UID-full to UID-less
 > operation, how could we possibly expect a much more diverse set of
 > client applications to implement your recommended changes?

Because my recommended changes are simple, logical, require no
additional certificates, and make no assumptions about how much the
subject of a certificate knows about the issuers.

In any case, the section 6.1.4 needs to be augmented to explain how
the value of working_issuer_UID is updated in preparation for the
next certificate (e.g. set it to certificate Subject UID).

Anne
-- 
Anne H. Anderson             Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Date: Mon, 14 Feb 2000 15:44:34 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Recommended change to Unique Identifier handling
To: [email-masked]
Content-MD5: FEmlgx6orA8gFHIdwxrtyw==

Anne,

Ignoring for a moment Peter's question as to whether any Internet-domain
CAs actually populate UID, I am still curious how an interoperability
problem could arise.

In your example, CA2 has a SubjectUID=null, but it issues a cert to EE1
with IssuerUID=CA2-UID.  What is the motivation for CA2 to create such
an unorthodox cert?

Comments interspersed below ...

> From: Anne Anderson <[email-masked]>
> 
> There are problems with the processing of Unique Identifier values
> as currently specified in draft-ietf-pkix-new-part1-00.txt,
> including the following:
> 
> a) PKIX recommends that PKIX-compliant CAs should not set Subject
>    and Issuer UID values.  This makes it impossible for certificates
>    from non-compliant CAs that use UIDs to be used as links in a
>    chain that includes certificates from compliant CAs.  This
>    creates a serious interoperability problem during the period
>    before all CAs become fully PKIX-compliant.
> 
> b) Assuming a CA is willing to stray from the recommendation in the
>    interests of interoperability, then each time the CA signs a CA
>    certificate, it MUST know the Issuer Unique Identifier value that
>    the subject will store in certificates it generates, and must set
>    that value in the certificate's Subject Unique Identifier field.
>    Yet the subject may become PKIX-compliant and cease issuing
>    certificates with Issuer Unique Identifier values at any time.

In your example of CA1=anchor, CA2, and EE1:  when CA1 signs a
certificate for CA2, CA1 MUST know the Issuer UID that CA2 will store
in certificates it generates.  That's one way of looking at it, but
it seems to reverse cause and effect.  I would look at the situation
as:

 1) CA1 issues a cert to CA2 containing a null or non-null SubjectUID.
 2) CA2 uses its own SubjectUID as the IssuerUID in all EE certs it issues.

If CA2 wants to become PKIX-compliant and stop issuing UID certs, it
can request two certs from CA1 - one with SubjectUID populated to use
before the transition, and one with SubjectUID null to use afterwards.
Might as well rollover CA2's keypair at the same time, just to make it
obvious which EE certs belong in which path.

> c) Again, in the interests of interoperability, each time a CA signs
>    a certificate, it MUST know the Subject Unique Identifier stored
>    in any certificates that other CAs have signed for itself, and
>    MUST use that Subject Unique Identifier as the Issuer Unique
>    Identifier in ALL certificates it signs. Since Subject Unique
>    Identifier values are completely arbitrary, they may vary across
>    different CAs that create certificates for the same principal.
>    This creates an impossible situation.

If CA1, CAx, and CAy all issue certs to CA2 with different SubjectUIDs
(or different public keys or different Subject names), you have an
impossible situation.  UID is not unique in this respect - the issuers
simply can't be completely arbitrary in what they say about CA2 and
still expect paths to CA2's preexisting EEs to validate.

I don't think any change to PKIX UID processing rules is necessary.
Assuming that there are currently any CAs which use UIDs, if the CAs
can't manage themselves to transition from UID-full to UID-less
operation, how could we possibly expect a much more diverse set of
client applications to implement your recommended changes?

Dave Kemp

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Recommended change to Unique Identifier handling
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 15 Feb 2000 07:57:27 (NZDT)

Anne Anderson <[email-masked]> writes:

>There are problems with the processing of Unique Identifier values as
>currently specified in draft-ietf-pkix-new-part1-00.txt, including the
>following:
>
>a) PKIX recommends that PKIX-compliant CAs should not set Subject
>   and Issuer UID values.  This makes it impossible for certificates
>   from non-compliant CAs that use UIDs to be used as links in a
>   chain that includes certificates from compliant CAs.  This
>   creates a serious interoperability problem during the period
>   before all CAs become fully PKIX-compliant.

Given that no major[0] CA has ever used UID's, is this really an issue?  I 
assume (based on the above message) that someone somewhere is currently using 
them despite their having been deprecated for some time, but is it the job of 
PKIX to accomodate out-of-spec implementations?

Peter.

[0] "major" = visible enough that interoperability with others will be a 
    problem.

Date: Mon, 14 Feb 2000 13:49:01 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Cert comparison needs AI?
To: [email-masked], [email-masked]
Content-MD5: k9bXtm+kShyFyba8zm6PMw==

> From: Paul Koning <[email-masked]>
> 
> >>>>> "Anders" == Anders Rundgren <[email-masked]> 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."

From: Anders Rundgren <[email-masked]>
To: "'Paul Koning'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: QC: Indentication confusion continues
Date: Mon, 14 Feb 2000 19:41:22 +0100

Oops,
You are right.  Swedish and Finnish citizen registration numbers are (supposed to be) unique though.
Within their respectively naming domain only of course.

Anders

----------
From:  Paul Koning [SMTP:[email-masked]]
Sent:  Monday, February 14, 2000 17:37
To:  [email-masked]
Cc:  [email-masked]; [email-masked]; [email-masked]
Subject:  Re: QC: Indentication confusion continues

>>>>> "Anders" == Anders Rundgren <[email-masked]> writes:

 Anders> ...  I.e. that SSN's and similar unique identities ...

SSNs aren't unique identities.

	paul

Sender: [email-masked]
Date: Mon, 14 Feb 2000 10:40:18 -0800
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: Request for Opinion - LDAP Proxy in a PKI environment

Ed Greshko wrote:
> 
> Hello,
> 
> A question has begun to crop up in various places about the suitability of
> using an LDAP proxy with caching in a PKI environment.  The particular
> environment in question uses CRLs stored in a single LDAP object.
> 
> My initial reaction to this is that it would be undesirable to deploy a
> proxy with caching.
> 
> I'm interested in what views others would have.....
> 
> Thanks,
> Ed

You are essentially correct, Ed.

The caching proxy basically becomes a trusted entity, because you're trusting
it to notice that the CRL has been updated in the CA's directory server. 
Because a user has no way of knowing whether or not a CRL has been issued
before the previous CRL's nextUpdate time, the user has to trust the proxy to
fetch new CRLs.

This makes the proxy a target for attacks, because if I can get your proxy to
serve stale-but-unexpired CRLs I can get you to accept a recently-revoked
certificate.

This applies to all kinds of caching proxies, not just LDAP ones.  OCSP
suffers the same problem when caching HTTP proxies are used.  In a PKI, you
have to trust your direct source of information, be it a proxy, a directory,
or a CA's own server.

The implications of this for using untrusted directories in a PKI is left as
an exercise for the reader.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Mon, 14 Feb 2000 12:20:59 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Cert comparison needs AI?

>>>>> "Anders" == Anders Rundgren <[email-masked]> 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?

	paul

Date: Mon, 14 Feb 2000 11:51:13 -0500 (EST)
From: Anne Anderson <[email-masked]>
To: [email-masked]
Subject: Recommended change to Unique Identifier handling

There are problems with the processing of Unique Identifier values
as currently specified in draft-ietf-pkix-new-part1-00.txt,
including the following:

a) PKIX recommends that PKIX-compliant CAs should not set Subject
   and Issuer UID values.  This makes it impossible for certificates
   from non-compliant CAs that use UIDs to be used as links in a
   chain that includes certificates from compliant CAs.  This
   creates a serious interoperability problem during the period
   before all CAs become fully PKIX-compliant.

b) Assuming a CA is willing to stray from the recommendation in the
   interests of interoperability, then each time the CA signs a CA
   certificate, it MUST know the Issuer Unique Identifier value that
   the subject will store in certificates it generates, and must set
   that value in the certificate's Subject Unique Identifier field.
   Yet the subject may become PKIX-compliant and cease issuing
   certificates with Issuer Unique Identifier values at any time.

c) Again, in the interests of interoperability, each time a CA signs
   a certificate, it MUST know the Subject Unique Identifier stored
   in any certificates that other CAs have signed for itself, and
   MUST use that Subject Unique Identifier as the Issuer Unique
   Identifier in ALL certificates it signs.  Since Subject Unique
   Identifier values are completely arbitrary, they may vary across
   different CAs that create certificates for the same principal.
   This creates an impossible situation.

EXAMPLE
=======

To illustrate these problems, consider the following path example,
and assume that everything except the IssuerUID verifies:

Trust anchor: Issuer:  CA1
              Subject: CA1
              IssuerUID: null
              SubjectUID: null

2nd cert:     Issuer:  CA1
              Subject: CA2
              IssuerUID: null
              SubjectUID: null

3rd cert:     Issuer:  CA2
              Subject: EE1
              IssuerUID: CA2-UID
              SubjectUID: null

According to the current draft-ietf-pkix-new-part1-00.txt, this
certification path should be rejected at the 3rd certificate since
the Issuer Unique Identifier in the 3rd certificate does not match
the "working_issuer_UID", which is null.

RECOMMENDED CHANGES
===================

To address these problems, I recommend that Unique Identifier
matching be used as part of path processing only if the preceding
certificate has a non-null Subject Unique Identifier and the current
certificate has a non-null Issuer Unique Identifier.

In other words, absence of a Subject Unique Identifier field in a
certificate logically means the issuer does not care what Issuer
Unique Identifier value (if any) is used in subsequent certificates.

And, absence of an Issuer Unique Identifier value in a certificate
logically means the issuer does not care (or know) what Subject
Unique Identifier was used in certificates that might preceed this
one in a certification path.

Recommended changes to the text of draft-ietf-pkix-new-part1-00.txt:

[Change 6.1.3 (5) to:]
   6.1.3 Basic Certificate Processing
   ....
         (5) If the certificate issuer unique identifier field is
             present and non-null, and if the working_issuer_UID is
             non-null, then the value of the certificate issuer unique
             identifier must match the value of the working_issuer_UID.

[Add 6.1.5 (h):]
   6.1.5 Wrap-up procedure

   To complete the processing of the end entity certificate, perform the
   following steps for certificate n:
   ....
      (h) If the certificate subject unique identifier field is
          present and non-null, set the value of working_issuer_UID
          to the value of the certificate subject unique identifier
          field.  Otherwise, set the value of working_issuer_UID to
          null.

Anne
-- 
Anne H. Anderson             Email: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Date: Mon, 14 Feb 2000 11:36:35 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: QC: Indentication confusion continues

>>>>> "Anders" == Anders Rundgren <[email-masked]> writes:

 Anders> ...  I.e. that SSN's and similar unique identities ...

SSNs aren't unique identities.

	paul

From: Anders Rundgren <[email-masked]>
To: Stephen Kent <[email-masked]>, "'Ed Gerck'" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Magnus Nystrom'" <[email-masked]>
Subject: RE: Identification confusion continues
Date: Mon, 14 Feb 2000 17:09:12 +0100

Thanx Ed!
It would be particularly interesting to know who actually use or intend to use serialNumber as a
name collision eliminator.  I.e. the function of dnQualifier according to ITU...

/anders

----------
From:  Ed Gerck [SMTP:[email-masked]]
Sent:  Monday, February 14, 2000 16:54
To:  Stephen Kent
Cc:  Anders Rundgren; [email-masked]
Subject:  Re: Identification confusion continues

>Stephen Kent wrote:

>> After extensive debate, folks in the ITU and IETF worlds agreed that
>> the syntax of what we needed is best expressed by serialNumbner, not
>> DNqualifier, and that a broadening of the definition of the former
>> attribute was the best path.  Moreover, we had reports from various
>> folks that people in the field had come to the same conclusion and
>> were already using serialNumber in this fashion.  So, we are
>> legitimizing current practice, and meeting a stated need, without
>> introducing a new attribute type.

>I may have missed this information in the draft?  Seems to me that it
>at least shows why the seemingly most obscure path was the path of
>choice, by calling a serialNumber what is not a "serial number".

>BTW, could we know what "people in the field had come to the same
>conclusion and were already using serialNumber in this fashion" and
>also who were the "various folks" that reported on this?  It might be
>useful to get back to both sides and see exactly what is being done
>ahead of the standards.

>Cheers,

>Ed Gerck

Date: Mon, 14 Feb 2000 07:53:59 -0800
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Anders Rundgren <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Identification confusion continues

Stephen Kent wrote:

> After extensive debate, folks in the ITU and IETF worlds agreed that
> the syntax of what we needed is best expressed by serialNumbner, not
> DNqualifier, and that a broadening of the definition of the former
> attribute was the best path.  Moreover, we had reports from various
> folks that people in the field had come to the same conclusion and
> were already using serialNumber in this fashion.  So, we are
> legitimizing current practice, and meeting a stated need, without
> introducing a new attribute type.

I may have missed this information in the draft?  Seems to me that it
at least shows why the seemingly most obscure path was the path of
choice, by calling a serialNumber what is not a "serial number".

BTW, could we know what "people in the field had come to the same
conclusion and were already using serialNumber in this fashion" and
also who were the "various folks" that reported on this?  It might be
useful to get back to both sides and see exactly what is being done
ahead of the standards.

Cheers,

Ed Gerck

Date: Mon, 14 Feb 2000 10:31:42 -0500
To: Anders Rundgren <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Identification confusion continues
Cc: "[email-masked]" <[email-masked]>

At 8:13 AM +0100 2/14/00, Anders Rundgren wrote:
>Stefan,
>
>  >Your way of using serialNumber fits well in the QC definition. We could not
>  >limit the use of serialNumber to a static identifier based on the past
>  >discussions.
>
>And your way of assigning multiple semantics to an object without having
>any disambiguiting element is a practice that usually renders you a 
>kick in the rear in most places of this industry.
>To put such constructs in an international standard-to-be is 
>definitely a step up on the penalty ladder.
>
>/Anders

After extensive debate, folks in the ITU and IETF worlds agreed that 
the syntax of what we needed is best expressed by serialNumbner, not 
DNqualifier, and that a broadening of the definition of the former 
attribute was the best path.  Moreover, we had reports from various 
folks that people in the field had come to the same conclusion and 
were already using serialNumber in this fashion.  So, we are 
legitimizing current practice, and meeting a stated need, without 
introducing a new attribute type.

Steve

Date: Mon, 14 Feb 2000 14:38:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

Keeping the flames from Mr Manuel Heras-Gilsanz out of the debate,
let us see how we can modify the draft for "the benefit of
interoperability with alien civilisations !! ".    :-)

My role, as the lead editor, is to try to obtain a working group
consensus. Thanks to Tom Gindin for his proposal leading the way to
a consensus.

We need to solve three issues if we want to guarantee a smooth
co-existence of the two standards.

1. the form of the request,
2. the error codes attached with the response,
3. the form of the response.

1. The form of the request

Tom's proposal, agreed by Roland, is for ISO to add an optional
mechanism parameter that will be defaulted to the IETF mechanism,
i.e. digital signature.

This allows the same server to listen to the same port and respond
to IETF conformant requests or ISO conformant requests, provided
that ISO adopts the same parameters of the request that the IETF
defines.

In practice we will have the ISO protocol as a superset from the
IETF protocol. If someone wants to speak of one protocol but not the
other how should we name it ? Since everything is very simple with
our WG (think about SCVP), why don't we rename it: "Simple Time
Stamping Protocol (STSP)" ?

ISO could then call their version something like "eXtended Time
Stamping Protocol (XTSP)"or, whatever they like, provided that the
name is different.

2. The error code attached with the request or the response

It is anticipated that ISO will need a few error codes that are not
all yet defined. These error codes must not collide. The best way I
see to deal with this issue is that we reserve some error codes in
our specification and let them know that they are exclusively to be
allocated by ISO SC 27. We do not even need to say in the
specification that they are for ISO. The IETF WG (and chairs) will
remember not to use them for IETF purposes. However we need to know
how many they anticipate. Five, ten ?

3. The form of the response

The response may be quite different, so there is no need for
alignment. However, it will be certainly useful to be able to
reference the two data structures from the response so that they can
be used in other data structures. We have done this for our data
structure in the annex A where we define a Signature Timestamp
attribute using the following object identifier:

id-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) 
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa (2)
id-aa-timeStampToken (14)}

ISO might wish to define another OID for their data structure which
will have to bear a name different from "SignatureTimeStampToken ".
I would suggest that they use someting like
"SignatureExtendedTimeStampToken" or anything else they wish,
provided that it is different.

Other matters: Response to Tom's questions

I answered to Tom's first question (should the mechanismNotSupported
bit be added to PKIFailureInfo in the PKIX draft?) by proposing to
reserve a few error codes (to ISO).

The second question raised by Tom, was: "Should the ISO ASN.1 format
for TimeStampReq and TSTInfo be documented in an appendix to the
PKIX draft, pointing out that these are fully compatible with the
PKIX definitions within the existing draft?

The answer to that question is fairly simple. No, because we can't !
We do not know yet what they will be, be since the ISO process is
still long and no one can predict what will be the final result. We
cannot wait until the completion of the ISO work to publish our
standard.

Conclusion

Besides the other minor fixes around the ASN1 syntax, I believe that
we are now close to a consensus. I would like to hear about the WG
to see if this opinion is shared and then I will post to the mailing
list the changes that I propose as a result of the last call.

Please, leave flames out of the debate.  :-)

Regards,

Denis

From: "Kwon, YongChul" <[email-masked]>
To: <[email-masked]>
Subject: salt in Password Based MAC
Date: Mon, 14 Feb 2000 20:32:23 +0900
Importance: Normal

How should I make the first input value of first iteration of PBM?

salt||sharedsecret or sharedsecret||salt? ('||' means concatenation)

I think RFC-2510 said message||salt, but I can't sure. :-(

I attach part of RFC-2510 which refers how to make initial input.

-----

3.1.3 PKI Message Protection

...

In the above protectionAlg the salt value is appended to the shared
secret input. The OWF is then applied iterationCount time, where
the salted secret is the input to the first iteration and

...

From: [email-masked]
To: [email-masked]
Date: Mon, 14 Feb 2000 10:47:48 +0100

subscribe

From: Anders Rundgren <[email-masked]>
To: "'Magnus (RSA)'" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Cc: "'SEIS-List'" <[email-masked]>
Subject: RE: Cert comparison needs AI?
Date: Mon, 14 Feb 2000 08:39:19 +0100

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.

Noop. In the absence of defined semantics, this property or quality MUST be a part
of a valid QC CPS.   The German (QC sample?) CPS must state that you can't compare
German QCs (or do it on your own risk) while the Swedish and Finnish ID-card programs
guarantee that you can trust the static unique ID as being the sole attribute to
compare (after you have detected that the cert really is belonging to these domains).

Note: computer do not "care".  They run algorithms based on a usually limited set of rules.

If the governing humans do not know how to express the rules, the programmers making applications
are likely to fail as well.  As programmers also are humans.  

/anders

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Sunday, February 13, 2000 13:50
> To: Magnus (RSA); [email-masked]; Stefan Santesson
> Subject: QC: Cert compariosion needs AI?
>
>
> Guys,
>
> >From section 4 security:
>
>    >Comparing two qualified certificates to determine if they
> represent
>    >the same physical entity may provide misleading results
> and should be
>    >performed with care.
>
> Since the relying party is in most cases is a server-computer
> I would be happy to get
> the Java source code for "performed with care".  :-) :-) :-)
>
> Of course a slippery statement like that is not even worth
> the paper it is written on.
> In the "real" world we need down-to-earth solutions which
> means that all this
> is currently completely out of the draft.
>
> Anders
>

From: Anders Rundgren <[email-masked]>
To: "'Magnus (RSA)'" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Identification confusion continues
Date: Mon, 14 Feb 2000 08:13:01 +0100

Stefan,

>Your way of using serialNumber fits well in the QC definition. We could not
>limit the use of serialNumber to a static identifier based on the past
>discussions.

And your way of assigning multiple semantics to an object without having
any disambiguiting element is a practice that usually renders you a kick in the rear in most places of this industry.
To put such constructs in an international standard-to-be is definitely a step up on the penalty ladder.

/Anders

From: "Stefan Santesson" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Magnus \(RSA\)'" <[email-masked]>, <[email-masked]>
Subject: RE: Cert compariosion needs AI?
Date: Mon, 14 Feb 2000 07:55:00 +0100
Importance: Normal

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.

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Sunday, February 13, 2000 13:50
> To: Magnus (RSA); [email-masked]; Stefan Santesson
> Subject: QC: Cert compariosion needs AI?
>
>
> Guys,
>
> >From section 4 security:
>
>    >Comparing two qualified certificates to determine if they
> represent
>    >the same physical entity may provide misleading results
> and should be
>    >performed with care.
>
> Since the relying party is in most cases is a server-computer
> I would be happy to get
> the Java source code for "performed with care".  :-) :-) :-)
>
> Of course a slippery statement like that is not even worth
> the paper it is written on.
> In the "real" world we need down-to-earth solutions which
> means that all this
> is currently completely out of the draft.
>
> Anders
>

From: "Stefan Santesson" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Magnus \(RSA\)'" <[email-masked]>, <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Subject: RE: Indentication confusion continues
Date: Mon, 14 Feb 2000 07:52:01 +0100
Importance: Normal

Anders,

Your way of using serialNumber fits well in the QC definition. We could not
limit the use of serialNumber to a static identifier based on the past
discussions.

/Stefan

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Sunday, February 13, 2000 09:05
> To: Magnus (RSA); [email-masked]; Stefan Santesson
> Subject: QC: Indentication confusion continues
>
>
> Guys,
> After a quick reading of the QC-03 draft I am pretty puzzled.
>
> You have simply renamed dNqualifier into serialNumber.  Where
> did last years endless
> discussion landed?
>
> serialNumber is now made into a name collosion eliminator
> which is a completely different
> task than it has in for example the Swedish and Finnish
> ID-card programs which was one
> of the reasons to switch from dnqualifier.
>
> In those systems serialNumber is a unique identitity and
> other attributes are simply "informative".
>
> You had a number of options to solve this but I can't see any
> traces of this in the draft.
> Of course a CA can define a unique QC statement saying how
> attributes are to be used but that
> is totally redundant and requires proprietary interpretation
> at run-time.
>
> So basically you have "smart-coded" serialNumber into having
> multiple semantics which
> is plain stupid when there are existing attributes like qnQualifier.
>
> Or is it still the "politically correct issues" that haunts
> this draft?.  I.e. that SSN's and similar
> unique identities should not be directly supported  as it
> could be interpreted
> as a recommendation?
>
> Anders

From: "Manger, James H" <[email-masked]>
To: "'Roland Mueller'" <[email-masked]>, [email-masked]
Subject: RE: Time-stamping: IETF / ISO
Date: Mon, 14 Feb 2000 10:34:34 +1100

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

Please follow the standard ASN.1 extensibility rules if adding a new field
(e.g. mechanism) to a syntax (e.g. TSTInfo).  That is, the new field must be
added to the end of the SEQUENCE and must be optional.

----------
From:	[email-masked] [mailto:[email-masked]]
Sent:	Friday, 11 February 2000 14:09

..ISO include the mechanism identifiers in their ASN.1 definitions and
specify them with default values..

------_=_NextPart_000_01BF767A.E264346E
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BF767A.E264346E--

From: Ambarish Malpani <[email-masked]>
To: "'Marc Jadoul'" <[email-masked]>, Massimiliano Pala <[email-masked]>
Cc: [email-masked], IETF-PXIX <[email-masked]>
Subject: RE: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).
Date: Sun, 13 Feb 2000 09:48:04 -0800

Yes, this is possible - you can have two different keys for
a CA, one to sign certs and another to sign CRLs. And yes,
it does work (at least with some of the software out there).
However, these are still both the CAs keys.

There are also "Indirect CRL"s, which can be produced by
one entity saying what is revoked by another entity (a CA).
Not sure how much of the software out there supports that.

Regards,
Ambarish

> -----Original Message-----
> From: Marc Jadoul [mailto:[email-masked]]
> Sent: Sunday, February 13, 2000 5:03 AM
> To: Massimiliano Pala
> Cc: [email-masked]; IETF-PXIX
> Subject: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).
> 
> 
> "Salz, Rich" wrote:
> > 
> > >can CRLs be signed by a certificate that is not the CA certificate
> > 
> > No.
> 
> Ok, but may be there is a solution (that i never tried and it might be
> uncompatible with lot of existing software.) :
> 
> If i understand well, you do not want to have your CA keys online for
> security reason ? Or more precisely, you do not want to have some key
> online, because this key is able to sign certificates which would be
> verified by the CA certificate you published ... ?
> 
> But if you generate a second key for your CA, and use this 
> key ONLY for
> signing CRL, you can achieve what you want.
> 
> Of course you need to sign a CA certificate for this new key. This
> certificate would be signed by your main (old) CA key, but 
> you would use
> a keyUsage extension with only the crlSign bit set. Thus this
> certificate can not be used to verify certificates but can be used to
> verify CRLs.
> 
> It would be reasonably safe to have the second CA key online. At least
> it is as safe as what you can get with online signing of revocation
> status.
> 
> Note that you probably also need the keyid extension also to help
> software to find the good CA certificate.
> 
> Let me know if you think it is possible in real life.
> 
> Marc
> 

From: "Tor Rustad" <[email-masked]>
To: <[email-masked]>
Subject: subscribe
Date: Sun, 13 Feb 2000 15:57:14 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF763A.FEB63D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_0005_01BF763A.FEB63D00
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.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D1>
<P>subscribe</P></FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01BF763A.FEB63D00--

Sender: mgjadoul
Date: Sun, 13 Feb 2000 14:02:51 +0100
From: Marc Jadoul <[email-masked]>
Organization: BelSign NV/SA
To: Massimiliano Pala <[email-masked]>
CC: [email-masked], IETF-PXIX <[email-masked]>
Subject: Signing CRL with offline CA (was [Fwd: OCSP and CSL]).

"Salz, Rich" wrote:
> 
> >can CRLs be signed by a certificate that is not the CA certificate
> 
> No.

Ok, but may be there is a solution (that i never tried and it might be
uncompatible with lot of existing software.) :

If i understand well, you do not want to have your CA keys online for
security reason ? Or more precisely, you do not want to have some key
online, because this key is able to sign certificates which would be
verified by the CA certificate you published ... ?

But if you generate a second key for your CA, and use this key ONLY for
signing CRL, you can achieve what you want.

Of course you need to sign a CA certificate for this new key. This
certificate would be signed by your main (old) CA key, but you would use
a keyUsage extension with only the crlSign bit set. Thus this
certificate can not be used to verify certificates but can be used to
verify CRLs.

It would be reasonably safe to have the second CA key online. At least
it is as safe as what you can get with online signing of revocation
status.

Note that you probably also need the keyid extension also to help
software to find the good CA certificate.

Let me know if you think it is possible in real life.

Marc

From: "Anders Rundgren" <[email-masked]>
To: "Magnus (RSA)" <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: QC: Cert compariosion needs AI?
Date: Sun, 13 Feb 2000 12:50:08 -0000

Guys,

>From section 4 security:

   >Comparing two qualified certificates to determine if they represent
   >the same physical entity may provide misleading results and should be
   >performed with care.

Since the relying party is in most cases is a server-computer I would be happy to get
the Java source code for "performed with care".  :-) :-) :-)

Of course a slippery statement like that is not even worth the paper it is written on.
In the "real" world we need down-to-earth solutions which means that all this
is currently completely out of the draft. 

Anders

From: "Anders Rundgren" <[email-masked]>
To: "Magnus (RSA)" <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>
Subject: QC: Indentication confusion continues
Date: Sun, 13 Feb 2000 08:04:34 -0000

Guys,
After a quick reading of the QC-03 draft I am pretty puzzled.

You have simply renamed dNqualifier into serialNumber.  Where did last years endless
discussion landed?

serialNumber is now made into a name collosion eliminator which is a completely different
task than it has in for example the Swedish and Finnish ID-card programs which was one
of the reasons to switch from dnqualifier.

In those systems serialNumber is a unique identitity and other attributes are simply "informative".

You had a number of options to solve this but I can't see any traces of this in the draft.
Of course a CA can define a unique QC statement saying how attributes are to be used but that
is totally redundant and requires proprietary interpretation at run-time.

So basically you have "smart-coded" serialNumber into having multiple semantics which
is plain stupid when there are existing attributes like qnQualifier.

Or is it still the "politically correct issues" that haunts this draft?.  I.e. that SSN's and similar
unique identities should not be directly supported  as it could be interpreted
as a recommendation?

Anders

Date: Sat, 12 Feb 2000 11:39:28 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: announcement ivta.org

List:

Internet voting is a case where privacy must be protected, so that
arguments to justify losing voter privacy in the good name of security
are simply not possible.  Which  firmly posits security  as a protection
of privacy -- not as an enemy of privacy -- in the problem-solving
assumptions to be considered.

In this context, an international team of experts and companies are calling for
open discussions on Internet voting technology. A public founding
assembly will take place February 28 in Washington D.C. at 9 a.m.

Details at http://www.ivta.org

Cheers,

Ed Gerck

Reply-To: <[email-masked]>
From: "Ed Greshko" <[email-masked]>
To: <[email-masked]>
Subject: Request for Opinion - LDAP Proxy in a PKI environment
Date: Sat, 12 Feb 2000 13:28:10 +0800
Importance: Normal

Hello,

A question has begun to crop up in various places about the suitability of
using an LDAP proxy with caching in a PKI environment.  The particular
environment in question uses CRLs stored in a single LDAP object.

My initial reaction to this is that it would be undesirable to deploy a
proxy with caching.

I'm interested in what views others would have.....

Thanks,
Ed

From: Peter Williams <[email-masked]>
To: "'Roland Mueller'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Time-stamping: IETF / ISO
Date: Fri, 11 Feb 2000 15:08:10 -0800

Id suggest specifying a complete reference to the 
IETF mechanism(s) in a high-profile, but NON-normative
annex, only.  

-----Original Message-----
From: Roland Mueller [mailto:[email-masked]]
Sent: Friday, February 11, 2000 1:17 PM
To: [email-masked]
Cc: Manuel Heras Gilsanz; [email-masked]; [email-masked]
Subject: Re: Time-stamping: IETF / ISO

This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland

Date: Fri, 11 Feb 2000 22:43:32 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Life is hard, and then you die." <[email-masked]>, Denis Pinkas <[email-masked]>
CC: [email-masked], xme <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

Denis, Ronald,

I agree we should align these. However, there's an upcoming 
rev. of CMP (currently being tweaked on the ca-talk list by the
folks who've done the interop), so we do have the option
of adding the TSP values into CMP and moving the colliding
ones. Alternatively, we could add "ranges" into CMP
(not v. extensible though & it wastes bits). I don't
mind which way we do this, but we do need to get rid of
the collisions (and hopefully, prevent future collisions).
Either way, I reckon TSP can stick with its values and CMP can
change.

Regards,
Stephen.

"Life is hard, and then you're acquired:-)" wrote:
> 
> I'm probably a bit late for this, but here goes anyway. I have two
> comments, one related to the failure-info bits, one related to the
> transport mechanisms.
> 
> 1) I'm somewhat unhappy with allocation of values in the
>    PKIFailureInfo definition. Either don't even try to be compatible
>    with CMP (i.e.  just use 0, 1, 2, etc), or then use a different
>    space (e.g. 100, 101, etc). With the current definition the codes
>    conflict with or are intermingled with CMP defined values (it might
>    be a good idea to set a IANA registry for these values, or maybe
>    not).
> 
> 2) The transports are basically the same as 2510, which have been
>    shown to have problems. Two things specifically:
> 
>    A) Is polling needed at all? If so, why doesn't the http transport
>       allow for polling? Either both socket and http should define it,
>       or neither, as they both have similar semantics. Also, if
>       polling is indeed to be supported, some mechanism for connection
>       keep-alive signalling in the socket protocol is needed.
>       Actually, keep-alive signalling might be useful if applications
>       have whole bunches of documents they want timestamped.
> 
>    B) What is the partialMsgRep in the socket protocol good for? The
>       request message contains only single request, and the response
>       message contains a single structure which I don't see how and
>       why you would split up.
> 
>    Because I'm not really sure polling makes much sense here, the
>    easiest things might be to define the socket protocol as just
>    tsaMsg, finalMsgRep, and errorMsgRep, or even just the raw DER
>    encoded message as is done for HTTP (since it's DER encoded the
>    length is available in the first few bytes). Alternatively, reusing
>    the new transports from CMP would allow some folks to reuse
>    existing code (at the expense of extra work for those implementing
>    just TSP) and provide keep-alive signalling for the socket
>    protocol.
> 
>   Cheers,
> 
>   Ronald
> 
> P.S. Minor typo's: "Æ" is used (character 0xC6) instead of "'" in various
>      places.

From: [email-masked]
To: Roland Mueller <[email-masked]>, [email-masked]
cc: Manuel Heras Gilsanz <[email-masked]>, [email-masked]
Date: Fri, 11 Feb 2000 17:16:22 -0500
Subject: Re: Time-stamping: IETF / ISO

     Surely no apology is necessary.  If everyone who produced ASN.1 which
was later revised were considered at fault, no one would use it (which
perhaps would be a good thing, or perhaps not).  However, this leaves open
the question of whether the IETF specification should accomodate the ISO
one somewhat.  First, should the mechanismNotSupported bit be added to
PKIFailureInfo in the PKIX draft?  Second, should the ISO ASN.1 format for
TimeStampReq and TSTInfo be documented in an appendix to the PKIX draft,
pointing out that these are fully compatible with the PKIX definitions
within the existing draft?
     I realize that these suggestions come after last call completion, and
thus may be ruled out of order.

          Tom Gindin

Roland Mueller <[email-masked]> on 02/11/2000 04:16:52 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Manuel Heras Gilsanz <[email-masked]>, [email-masked],
      [email-masked]
Subject:  Re: Time-stamping: IETF / ISO

This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland

Date: Fri, 11 Feb 2000 15:16:52 -0600
From: Roland Mueller <[email-masked]>
Organization: TUVIT Inc.
To: [email-masked]
CC: Manuel Heras Gilsanz <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Time-stamping: IETF / ISO

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

This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland
--------------CC6A994B8F838D97A83974DE
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------CC6A994B8F838D97A83974DE--

From: "Life is hard, and then you die." <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
To: [email-masked]
Date: Fri, 11 Feb 2000 10:14:15 -0800 (PST)

I'm probably a bit late for this, but here goes anyway. I have two
comments, one related to the failure-info bits, one related to the
transport mechanisms.

1) I'm somewhat unhappy with allocation of values in the
   PKIFailureInfo definition. Either don't even try to be compatible
   with CMP (i.e.  just use 0, 1, 2, etc), or then use a different
   space (e.g. 100, 101, etc). With the current definition the codes
   conflict with or are intermingled with CMP defined values (it might
   be a good idea to set a IANA registry for these values, or maybe
   not).

2) The transports are basically the same as 2510, which have been
   shown to have problems. Two things specifically:

   A) Is polling needed at all? If so, why doesn't the http transport
      allow for polling? Either both socket and http should define it,
      or neither, as they both have similar semantics. Also, if
      polling is indeed to be supported, some mechanism for connection
      keep-alive signalling in the socket protocol is needed.
      Actually, keep-alive signalling might be useful if applications
      have whole bunches of documents they want timestamped.

   B) What is the partialMsgRep in the socket protocol good for? The
      request message contains only single request, and the response
      message contains a single structure which I don't see how and
      why you would split up.

   Because I'm not really sure polling makes much sense here, the
   easiest things might be to define the socket protocol as just
   tsaMsg, finalMsgRep, and errorMsgRep, or even just the raw DER
   encoded message as is done for HTTP (since it's DER encoded the
   length is available in the first few bytes). Alternatively, reusing
   the new transports from CMP would allow some folks to reuse
   existing code (at the expense of extra work for those implementing
   just TSP) and provide keep-alive signalling for the socket
   protocol.

  Cheers,

  Ronald

P.S. Minor typo's: "Æ" is used (character 0xC6) instead of "'" in various
     places.

From: [email-masked]
To: Manuel Heras Gilsanz <[email-masked]>
cc: [email-masked], [email-masked]
Date: Thu, 10 Feb 2000 22:08:59 -0500
Subject: Re: Time-stamping: IETF / ISO

     Would it be reasonable to suggest that ISO include the mechanism
identifiers in their ASN.1 definitions and specify them with default values
indicating the IETF standard mechanisms?  This would enable any use of the
IETF definition to interoperate with the ISO definition, without damaging
Roland's proposed definition in any way.
     In any case, I am reasonably sure that no alien race is likely to use
BER or DER with a definition compatible with ours down to the assigned
tags, so interoperation with them will not be affected by the presence or
absence of mechanism identifiers.

          Tom Gindin

Sender: manuel
Date: Thu, 10 Feb 2000 21:23:39 +0000
From: Manuel Heras Gilsanz <[email-masked]>
Organization: Visual Tools, S.A.
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Time-stamping: IETF / ISO

Dear Mr Pinkas,

> Roland,
> 
> Since you said that you want multiple mechanisms to be used and that
> it is NOT the intention of the ISO working group to introduce
> patented mechanisms, would you be able to provide at least one
> useful example of such a binding mechanism that is not patented ?
> 
> Denis

I would like to express some opinions on the management of this draft
with respect to ISO interoperability.

>From my point of view, what ISO is trying to do is to leave the
specification open, so that (in principle) *any* mechanism can be used,
either patented or non-patented. The fact that all the protocols we know
of today are or are not patented (something not at all clear, on the
other hand) is inessential, irrelevant and a pure contingency.

Imagine that we discover life outside Earth and we have to exchange
time-stamp tokens with a (possibly more advanced and therefore
patent-less) civilisation: we don't care whether their TS protocols are
patented or not; what we do is to evaluate the _mechanisms_ for
production of time-stamp tokens they use, and whether they can
interoperate with us. It would be a pity for you to see that aliens can
exchange time-stamps via ISO TS-standard but not via IETF TS-standard!
;-)

As I understand the issue, there is no problem in having several
different time-stamping standards (although this complicates the life of
many people, is inefficient, and creates artificial demand for security
consultants); what is really problematic is to have several
_incompatible_ standards (this should be punished with jail, and with
the death penalty when development of both standards took place in
parallel!!). What ISO is trying to do, from my point of view, is to
minimise the number and the degree of the incompatibilities between IETF
and ISO approaches.

The obstination that you are exercising from your position as IETF draft
editor is totally unacceptable to me. Your decisions should be based on
technical grounds, with the goal of benefiting the whole Internet
community. Don't try to convince us that you discovered two days ago
that ISO is working on a time-stamping standard, because you are also
taking a seat in the ISO working group, and taking good notes of the
discussions held therein.

I have not seen any technical reason why you don't accept ISO approach,
and it is my opinion that as an I-D editor your decisions should be
merely (or, at least, mostly) technical, as opposed to guided by
political or personal interests. The single technical responses of
relevance have been to propose the use the policy field as a way of
choosing the final format (ISO/IETF) of the item, which is other way of
saying "we don't want to be interoperable, you just put another layer on
the onion, and write the format there". (Policy identifiers cannot be
used for that -- nobody has yet agreed how policy identifiers from
different TSA relate, and how to know whether a certain policy-id is ISO
or IETF-oriented.)

Let me finally remind to you that Mr Roland Mueller is not a bored
newcomer suggesting funny changes in the last minute because he doesn't
know what to do in his spare time: he is coordinating the ISO
time-stamping effort, and as such his comments deserve a bit (more) of
attention and dissection on your part. I don't believe in authorities,
but at least we should recognise that his opinions reflect what many
experts have agreed after long, deep discussions, and his motivation is
to promote the compatibility between standards. I think you have
redirected his polite messages to /dev/null as if they came from "just
another one", something very inappropriate from your side. On the other
hand, ISO has been promoting interoperability since its earliest draft,
something I have not seen "from the other side". [Now let me clarify
that I am not a friend of Mr Mueller or part of his family, but I think
he is doing an excellent work as coordinator of the ISO ad-hoc group,
trying to listen to everybody's needs and opinions.]

It is very funny that, being ISO thought of as a "monolythic institution
suffering a lot of bureaucreacy and political influence, where strict
country representation rules govern", and the IETF as "the paradigm of
informal, electronic, open standards without heavy bureaucratic or
political influence, where anyone can participate and an individual can
influence the future of the net" [this is the mental image shared by
many people on both institutions], what we see here is that the "roles"
have been exchanged, and while ISO is warmly promoting easy
interoperation, and dialog, the IETF draft editors coldly find
themselves unable to incorporate the changes due to the proximity of the
closing date or simply dismissing the comments with dubious responses to
which they didn't give a couple of minutes' thought.

I encourage you to reconsider your position, as you might do a great
favour to all the Internet and security communities with the
introduction of the minor changes identified by the ISO working group as
potentially problematic, or at least participating in the dialogue after
leaving the ego at home.

If not in the benefit of human beings, please do it in the benefit of
interoperability with alien civilisations!!

Best regards,

       - Manuel Heras -
     [ I hate flaming, but this was too much! ]

Manuel Heras-Gilsanz
Security Consultant

Date: Thu, 10 Feb 2000 16:59:24 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Simon Tardell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: German Law and OCSP

Simon,

Thanks a lot for your response. However, I do not believe that the
interpretation you make will be the same as the interpretation from
Andreas. :-)

> > Before discussing the modifications or enhancements to be made to
> > OCSP I would like that we go back to the rational of making them.
> >
> > I have not been able to follow in details all the E-mails exchanges
> > on that topic, so if this has already be posted on the mailing list,
> > please indicate me in which message it is mentioned.
> >
> > I would like to go behind arguments like "this is required in
> > specification XXX". I would like to understand the rational of the
> > requirements and, once these are identified, if there would be other
> > solutions that could solve the same requirements.
> 
> > Changing a status in a spec. is an easy thing to do. Before doing
> > anything like this, we (i.e. the WG) have to understand the
> > implications.
> >
> > Once said, let us come to the technical side.
> >
> > It seems to me that the purpose of this new service is to offer an
> > additional guarantee which is that the certificate has really been
> > issued by the right CA and is not a forgery of a certificate made
> > using the CA compromised key.
> 
> This discussion is first and foremost about how to express additional
> assertions in OCSP (apart from revocation) in general, not any particular
> assertion.

A said above: Changing a status in a spec. is an easy thing to do.
Before doing anything like this, we (i.e. the WG) have to understand
the implications. 

> As you say, issuance is not a question if you have the certificate at hand
> and trust the CA certificate. However:

Sorry, this is not what I said. I considered the case of a CA key
compromise. In that case the certificate that you have at hand might
be a forged one, if the CA key has been compromised. So you do not
know whether it comes from the right CA or from the bogus CA.

> Andreas Berger wrote:
> > We had to extend the functionality (it was mid 1998 if I remember
> > correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> > design. We needed (as Hans has written)
> 
> > 1. Certificate was created, is in the service since T,
> > and is not revoked
> > 2. Certificate was created, is in the service since T, and is revoked
> > 3. Certificate is unknown
> 
> > which was not possible with then the OCSP.
> 
> In my understanding "is in service" means that the certificate can be
> produced at one time, but should not be usable until some later time, e.g.
> when the intended user confirms receipt of the corresponding token.

I do interpret "in the service since T" in the same way, so let us
ask the original writer (if he listens to the PKIX mailing list) to
say in a few words what this means, but also ask him to provide the
rational of the requirements that lead to the inclusion of that
sentence.

Denis

> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> [email-masked], http://www.iD2tech.com/
> voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999

From: Simon Tardell <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Thu, 10 Feb 2000 16:46:13 +0100

> Before discussing the modifications or enhancements to be made to
> OCSP I would like that we go back to the rational of making them.
> 
> I have not been able to follow in details all the E-mails exchanges
> on that topic, so if this has already be posted on the mailing list,
> please indicate me in which message it is mentioned.
> 
> I would like to go behind arguments like "this is required in
> specification XXX". I would like to understand the rational of the
> requirements and, once these are identified, if there would be other
> solutions that could solve the same requirements.

> Changing a status in a spec. is an easy thing to do. Before doing
> anything like this, we (i.e. the WG) have to understand the
> implications.
> 
> Once said, let us come to the technical side. 
> 
> It seems to me that the purpose of this new service is to offer an
> additional guarantee which is that the certificate has really been
> issued by the right CA and is not a forgery of a certificate made
> using the CA compromised key. 

This discussion is first and foremost about how to express additional
assertions in OCSP (apart from revocation) in general, not any particular
assertion. 

As you say, issuance is not a question if you have the certificate at hand
and trust the CA certificate. However:

Andreas Berger wrote:
> We had to extend the functionality (it was mid 1998 if I remember
> correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> design. We needed (as Hans has written)

> 1. Certificate was created, is in the service since T, 
> and is not revoked
> 2. Certificate was created, is in the service since T, and is revoked
> 3. Certificate is unknown

> which was not possible with then the OCSP. 

In my understanding "is in service" means that the certificate can be
produced at one time, but should not be usable until some later time, e.g.
when the intended user confirms receipt of the corresponding token.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

From: Sarbari Gupta <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>
Subject: FW: ISS Security Alert v.2
Date: Thu, 10 Feb 2000 10:38:38 -0500

I don't know how many of you are on the ISS mailing list - the information
seemed quite good.

=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================

-----Original Message-----
From: David Gerulski [mailto:[email-masked]] 
Sent: Wednesday, February 09, 2000 6:12 PM
To: [email-masked]
Subject: ISS Security Alert v.2

TO UNSUBSCRIBE: email "unsubscribe customerconnect" in the body of your
message to [email-masked].  Contact [email-masked] for
help with any problems!
---------------------------------------------------------------------------

Dear ISS Customer Connect Recipient,

Recent Internet attacks have targeted a number of high-profile Internet
sites such as Yahoo!, Buy.com, E-Bay, Amazon and CNN Interactive.  These
attacks are "Denial-Of-Service" attacks which are designed to bring down an
enterprise network or e-commerce site by flooding it with large amounts of
traffic, similar to hundreds of people repeatedly dialing a telephone number
to keep it busy.

While it is impossible to eliminate all risks from these attacks, Internet
Security Systems (ISS) recommends several steps that you should take if you
find your Internet site is under attack.  ISS also recommends several steps
that you can take before an incident to reduce the risk and possible impact
of these attacks.  

STEPS TO TAKE IF YOU ARE UNDER ATTACK:

*	Assemble an Incident Response Team
*	Get help from ISP and CERT
*	Involve Law Enforcement authorities
*	Monitor systems during the attack

DETAILS:

If you find yourself under attack, stay calm.  Here are 4 concrete steps you
can take to keep control of the situation:

1. Assemble an Incident Response Team.  This team should include senior
technical staff who can help formulate a plan of action, and should have
access to senior management who can authorize the action.  One key role of
this team is to have a contact person to coordinate with other organizations
(e.g. CERT, below) during the incident.

2. Get help.  Contact your Internet Service Provider (ISP) to inform them of
the attack.  It is possible that the ISP can take action to block the
attacks before they reach your computer systems.  Call the Computer
Emergency Response Team (CERT).  You can email them at [email-masked] or fax
them pertinent information at +1 (412) 268-6989.  You can also contact ISS
at [email-masked].  Include information about:

*	your name, telephone number, email address, and time zone 
*	the name and IP address of the system under attack, 
*	the apparent source of the attack (hostname or IP address)
*	a description of the attack (methods, tools, etc)

3. Contact Law Enforcement authorities to inform them of the incident.  You
may not be the only organization under attack, and they may be able to
provide technical assistance or contacts to help your response efforts.  You
can help the law enforcement efforts by collecting system log information
from target systems.  These logs may be important evidence that law
enforcement needs to take action; it is critical that this information be
collected and protected before it is accidentally (or deliberately) erased. 

4. Monitor important systems during the attack using intrusion detection
software or services.  This can help mitigate the attack, by discovering
actions that can be taken (e.g. installing security patches, expanding RAM
to help the OS to maintain performance during Denial-Of-Service attacks).
It can also help detect signs that this attack is more than a nuisance - for
example, that a Denial-Of-Service attack is a diversion intended to distract
your attention from an actual takeover of your systems.  In particular, if
other organizations are under particular attack, check any of your systems
that might be similar for signs of that attack as well.

STEPS TO TAKE BEFORE AN ATTACK:

*	Identify and empower an Incident Response Team
*	Perform a security audit or risk assessment of critical systems to
                identify risks
*	Mitigate the risks discovered, by installing appropriate security
                software
*	Learn more about Internet security issues

DETAILS:

There are also several things that you can do before an attack that will
greatly improve your ability to respond to an incident:

1. Put together an Emergency Response Plan, and identify a team who will be
responsible for implementing it.  Ensure that the team has senior management
contact, and the necessary technical skills.  The ISS X-Force offers a great
deal of technical information useful for technical staff education at
http://xforce.iss.net/. If these skills are not available in-house, consider
outsourcing this from a company offering Emergency Response Services. ISS'
Emergency Response Services (ERS) are specifically geared to help companies
build and improve upon incident preparedness. This is achieved through
quarterly on site workshops with customers.  This service then helps ISS'
Emergency Response Team be more effective with its 24x7 service in the event
that the client comes under attack.  The Emergency Response Plan should
include an escalation policy, and you should educate your organization on
this policy.

2. Perform an audit of critical business systems, to identify possible
vulnerability to attack.  Take appropriate action to mitigate any identified
risks - for example, by ensuring the Operating System is up-to-date.  This
Security Assessment should include determining any dependencies (like ISP's
and Web hosting companies) and what their protection level is.  It should
also examine network design for security resilience to Denial-Of-Service
attack.  

3. Take action to mitigate risks that are discovered: for example, implement
proper security management infrastructure and applications. (e.g. Intrusion
Detection Systems, Vulnerability Scanning, Firewalls, VPNs, etc). Send
syslog information from your routers to an analysis machine to examine for
evidence of an attack.  By watching for attacks, so you can detect and
respond to them early.  The earlier you detect an incident, the earlier you
can respond to it.  

4. To learn more about Distributed Denial Of Service attacks or about
Internet security issues in general, read the latest ISS X-Force Security
Advisories at http://xforce.iss.net.  In particular, Advisory 43
http://xforce.iss.net/alerts/advise43.php3 discusses these attacks in great
detail.

INFORMATION FOR ISS CUSTOMERS:

On top of developing public security advisories, the ISS X-Force is always
researching, and developing countermeasures within all of our ISS SAFEsuite
and ePatrol Managed Security Service solutions to help protect against
Denial-Of-Service attacks especially from new, high risk attacks such as
Tribe Flood Network and trin00.  ISS customers are advised to ensure that
ISS products are up-to-date: Internet Scanner, System Scanner, and
RealSecure have released Updates to help reduce the risk of these attacks:

SAFEsuite Security Assessment
An Internet Scanner X-press Update is available from
https://www.iss.net/update/InternetScanner/XPressUpdate3_1.xpu

A System Scanner X-Press Update is available from
http://www.iss.net/support/flexchecks/sscanner.php

SAFEsuite Intrusion Detection
An updated version of RealSecure (version 3.2.1) is available from
https://www.iss.net/cgi-bin/download/release/custDown.cgi

For more information on Denial of Service Attacks and a host
of other topics, join us for ISS Connect 2000: International User
Group and Security Summit this March 19th - 24th.

http://connect.iss.net
1-800-416-8749

*******************************************************************
                         ISS CONNECT 2000
International User Group and Information Security Summit
    March 19-24, 2000                  http://connect.iss.net
                          REGISTER TODAY!
*******************************************************************

Date: Thu, 10 Feb 2000 14:34:06 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Simon Tardell <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: German Law and OCSP

Ambarish and Simon,

Before discussing the modifications or enhancements to be made to
OCSP I would like that we go back to the rational of making them.

I have not been able to follow in details all the E-mails exchanges
on that topic, so if this has already be posted on the mailing list,
please indicate me in which message it is mentioned.

I would like to go behind arguments like "this is required in
specification XXX". I would like to understand the rational of the
requirements and, once these are identified, if there would be other
solutions that could solve the same requirements.

Changing a status in a spec. is an easy thing to do. Before doing
anything like this, we (i.e. the WG) have to understand the
implications.

Once said, let us come to the technical side. 

It seems to me that the purpose of this new service is to offer an
additional guarantee which is that the certificate has really been
issued by the right CA and is not a forgery of a certificate made
using the CA compromised key. 

If so, it thus seems to me that the problem that is attempted to be
addressed has to do with the possible compromise of a CA key.
Applying the usual security process leads to the following: this is
a rather seldom event. However, in case of the occurence of that
unlikely event a "disaster recovery plan" is needed and must be
established in advance. This means that usual operations do not
necessarilly need to be encumbered by an additional complexity (or
new protocols) and that the additional complexity should only occur
at the time the event occurs.

I also got the impression that, if this is the problem to be solved,
unless we define an alternative to address the same issue, it could
become MANDATORY to use this additional guarantee, making on-line
queries mandatory (we have all heard recently of denial of service
attacks).

I would first like to make sure that this understanding is correct.
Is it ?

Regards,

Denis

> > Hi Simon,
> >     You describe the situation very well. If I were trying to provide
> > additional semantics, I would do them through extensions.
> 
> Thanks, Ambarish. If this is the intention behind RFC2560 [model 2) below]
> then then perhaps a clarification should be made to the RFC. This to avoid
> several OCSP profiles that are mutually incompatible.
> 
> There are a couple of points that come to mind: The last few paragraphs of
> 3.2 where the possible certificate status values are described indicate that
> "good" means "cert is not revoked" && good_A && good_B ... and that the
> answer MAY be qualified by extensions. That is contradicting what you just
> said (since CertStatus would not be orthogonal to the extensions). On the
> other hand it does not say that "revoked" means "cert is revoked" || bad_A
> || bad_B ... In other words, the definition of "good" and "revoked" are not
> the positive and negative answers to the same question!
> 
> In addition, "unknown" should perhaps be redefined as "the responder does
> not have enough information to answer the question" to remove all doubt.
> 
> > For example,
> > if a client wanted to know whether a cert was issued or not, in
> > addition to its revocation status, I would recommend putting that
> > additional status information in singleExtensions, rather than
> > trying to overload the meaning of good.
> 
> Now, I think there are fairly good arguments for model 1). In the end, what
> matters if it is ok to use the certificate or not, the reason may really
> vary, but is of less importance to whoever is refusing service as a result
> of the reply. In model 2) you would put an equivalence between "error -- I
> don't understand what it says here" and "no, you can't do that". But the
> important message is the "no, you can't do that" not the "because ...", so
> making the "because ..." part critical seems unnecessary. Also, you would
> loose the distinction between "if you don't understand why you can't do
> that, it doesn't matter, just don't" and "you really should understand
> this". The latter is an exceptional condition while the former is not.
> Treating exceptional conditions (unhandled critical extensions) as a normal
> condition would require a quite clear wording about this in the RFC to make
> sure all clients understand the semantics in the same way.
> 
> But, either model is fine with me, as long as a clear choice is made in the
> RFC.
> 
> > The issue of whether a cert was ever issued or not, did come up, but
> > the group concensus was that a client either had the cert in hand and
> > could verify the signature on the cert and so know whether it was
> > issued or not.
> >
> > If the CA's cert signing key was compromised and you wanted to deal
> > with that case, you need to either directly trust the OCSP responder
> > and ask it about the CA's self signed cert, or check the CA's cert
> > if it is part of a larger hierarchy, or try to deal with the issue in
> > an out of band way.
> 
> Agreed. However, "issuance" has a slightly different semantics in the German
> specs. The certificate may not be valid for use until some time after its
> actual production (an unknown amount of time). That property needs to be
> answered by a German OCSP responder.
> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> [email-masked], http://www.iD2tech.com/
> voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999
> 
> > > Ambarish wrote:
> > >
> > > >     There are ways of profiling the spec that work within the
> > > > parameters defined by OCSP. In other ways, you break the design
> > > > of the basic protocol. In my opinion, this is the latter, not
> > > > the former.
> > >
> > > The German requirements raise the question what would be the "canonical"
> way
> > > of extending OCSP. This is not quite clear to me from reading the RFC.
> In my
> > > mind the scope of OCSP is to answer binary status queries on
> certificates
> > > (good, bad and possibly "don't know"). The natural question to ask is
> that
> > > of revocation. The Germans need to answer that of issuance. Still more
> can
> > > be imagined.
> > >
> > > In RFC2560 CertificateStatus can be set to "good", "revoked" or
> "unknown".
> > > The wording is a bit unclear here: Does "unknown" mean that "I don't
> know
> > > whether this certificate is revoked" or "I know this certificate does
> not
> > > exist"? The Germans seem to have opted for the latter interpretation.
> Now,
> > > assuming the former interpretation we have three answers to the
> revocation
> > > question (good, bad, don't know). How do we extend OCSP to assert the
> answer
> > > to other questions? I see two possible approaches:
> > >
> > > 1)
> > > CertificateStatus is generalized so that it contains the logical sum of
> all
> > > properties that the client wants to have asserted (or that the responder
> > > wants to assert in response to a query). E.g. assume two properties A
> and B
> > > that both have to be "good" for a certificate to be valid for use, then
> > > CertificateStatus is "good" if both of them are "good", "bad" if (at
> least)
> > > one of them is "bad" unless one of them is "unknown" in which case
> > > CertificateStatus is "unknown". Extensions to the respective statuses
> can be
> > > used to qualify the answer (e.g. to tell _what_ properties were bad), if
> the
> > > client really cares.
> > >
> > > 2)
> > > CertificateStatus is defined to only provide good, bad and unknown
> answers
> > > to the revocation question. SingleExtensions are defined for each
> property
> > > (except for revocation status) and each such SingleExtension can take
> the
> > > value "good", "bad" and "unknown". The problem then arises that the
> client
> > > can perhaps not be expected to understand new properties (extensions) as
> > > they are implemented on the server. To solve that, these extensions
> should
> > > be marked critical if they are "bad" or "unknown", but not if they are
> > > "good".
> > >
> > > Now, this is not quite what it says in the RFC (for example, the answer
> > > "good" allows to be qualified with other types of goodness, but there is
> > > seemingly no way to answer "not revoked, but bad in some other sense").
> The
> > > former method seems more attractive from the perspective that it allows
> > > making the clients simpler, but it would require some changes to the
> current
> > > protocol. The latter solution would work with current clients (how
> widely
> > > deployed are they anyway?) but is less appealing (an error in the client
> > > would have the meaning "no, you can't do that"...).

From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Subject: New draft profile for Qualified Certificates
Date: Thu, 10 Feb 2000 01:22:22 +0100
Importance: Normal

All,

We have submitted a new, and hopefully final, draft profile for Qualified
Certificates.

In this draft we have included the consensus from the latest intensive
discussions.

I would like to draw the attention to the fact that there are some
substantial changes in this document which includes:
- The personalData solution is removed from the draft
- Use of subjectDirectoryAttributes extension is added as replacement.
- The pseudonym attribute has got a new standard OID (X.520)
- dnQualifier is replaced with the serialNumber attribute

In addition to this there are some minor changes and ASN.1 updates.

Due to a broken link error in the IETF web page, you must follow this URL to
find the new draft (the current pointer on the IETF page is pointing to the
old non-existing draft)

http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-03.txt

At this moment I don't know of any unsolved issues.

/Stefan

From: Simon Tardell <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Wed, 9 Feb 2000 11:10:34 +0100 

> Hi Simon,
>     You describe the situation very well. If I were trying to provide
> additional semantics, I would do them through extensions. 

Thanks, Ambarish. If this is the intention behind RFC2560 [model 2) below]
then then perhaps a clarification should be made to the RFC. This to avoid
several OCSP profiles that are mutually incompatible.

There are a couple of points that come to mind: The last few paragraphs of
3.2 where the possible certificate status values are described indicate that
"good" means "cert is not revoked" && good_A && good_B ... and that the
answer MAY be qualified by extensions. That is contradicting what you just
said (since CertStatus would not be orthogonal to the extensions). On the
other hand it does not say that "revoked" means "cert is revoked" || bad_A
|| bad_B ... In other words, the definition of "good" and "revoked" are not
the positive and negative answers to the same question! 

In addition, "unknown" should perhaps be redefined as "the responder does
not have enough information to answer the question" to remove all doubt.

> For example,
> if a client wanted to know whether a cert was issued or not, in
> addition to its revocation status, I would recommend putting that
> additional status information in singleExtensions, rather than
> trying to overload the meaning of good.

Now, I think there are fairly good arguments for model 1). In the end, what
matters if it is ok to use the certificate or not, the reason may really
vary, but is of less importance to whoever is refusing service as a result
of the reply. In model 2) you would put an equivalence between "error -- I
don't understand what it says here" and "no, you can't do that". But the
important message is the "no, you can't do that" not the "because ...", so
making the "because ..." part critical seems unnecessary. Also, you would
loose the distinction between "if you don't understand why you can't do
that, it doesn't matter, just don't" and "you really should understand
this". The latter is an exceptional condition while the former is not.
Treating exceptional conditions (unhandled critical extensions) as a normal
condition would require a quite clear wording about this in the RFC to make
sure all clients understand the semantics in the same way.

But, either model is fine with me, as long as a clear choice is made in the
RFC.

> The issue of whether a cert was ever issued or not, did come up, but
> the group concensus was that a client either had the cert in hand and
> could verify the signature on the cert and so know whether it was
> issued or not.
> 
> If the CA's cert signing key was compromised and you wanted to deal
> with that case, you need to either directly trust the OCSP responder
> and ask it about the CA's self signed cert, or check the CA's cert
> if it is part of a larger hierarchy, or try to deal with the issue in
> an out of band way.

Agreed. However, "issuance" has a slightly different semantics in the German
specs. The certificate may not be valid for use until some time after its
actual production (an unknown amount of time). That property needs to be
answered by a German OCSP responder. 

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

> > Ambarish wrote:
> > 
> > >     There are ways of profiling the spec that work within the
> > > parameters defined by OCSP. In other ways, you break the design
> > > of the basic protocol. In my opinion, this is the latter, not
> > > the former.
> > 
> > The German requirements raise the question what would be the "canonical"
way
> > of extending OCSP. This is not quite clear to me from reading the RFC.
In my
> > mind the scope of OCSP is to answer binary status queries on
certificates
> > (good, bad and possibly "don't know"). The natural question to ask is
that
> > of revocation. The Germans need to answer that of issuance. Still more
can
> > be imagined.
> > 
> > In RFC2560 CertificateStatus can be set to "good", "revoked" or
"unknown".
> > The wording is a bit unclear here: Does "unknown" mean that "I don't
know
> > whether this certificate is revoked" or "I know this certificate does
not
> > exist"? The Germans seem to have opted for the latter interpretation.
Now,
> > assuming the former interpretation we have three answers to the
revocation
> > question (good, bad, don't know). How do we extend OCSP to assert the
answer
> > to other questions? I see two possible approaches:
> > 
> > 1)
> > CertificateStatus is generalized so that it contains the logical sum of
all
> > properties that the client wants to have asserted (or that the responder
> > wants to assert in response to a query). E.g. assume two properties A
and B
> > that both have to be "good" for a certificate to be valid for use, then
> > CertificateStatus is "good" if both of them are "good", "bad" if (at
least)
> > one of them is "bad" unless one of them is "unknown" in which case
> > CertificateStatus is "unknown". Extensions to the respective statuses
can be
> > used to qualify the answer (e.g. to tell _what_ properties were bad), if
the
> > client really cares.
> > 
> > 2)
> > CertificateStatus is defined to only provide good, bad and unknown
answers
> > to the revocation question. SingleExtensions are defined for each
property
> > (except for revocation status) and each such SingleExtension can take
the
> > value "good", "bad" and "unknown". The problem then arises that the
client
> > can perhaps not be expected to understand new properties (extensions) as
> > they are implemented on the server. To solve that, these extensions
should
> > be marked critical if they are "bad" or "unknown", but not if they are
> > "good".  
> > 
> > Now, this is not quite what it says in the RFC (for example, the answer
> > "good" allows to be qualified with other types of goodness, but there is
> > seemingly no way to answer "not revoked, but bad in some other sense").
The
> > former method seems more attractive from the perspective that it allows
> > making the clients simpler, but it would require some changes to the
current
> > protocol. The latter solution would work with current clients (how
widely
> > deployed are they anyway?) but is less appealing (an error in the client
> > would have the meaning "no, you can't do that"...).

From: Ambarish Malpani <[email-masked]>
To: "'Simon Tardell'" <[email-masked]>, "'Andreas Berger'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Tue, 8 Feb 2000 09:39:03 -0800 

Hi Simon,
    You describe the situation very well. If I were trying to provide
additional semantics, I would do them through extensions. For example,
if a client wanted to know whether a cert was issued or not, in
addition to its revocation status, I would recommend putting that
additional status information in singleExtensions, rather than
trying to overload the meaning of good.

We went through a long discussion on how best to do this when OCSP
was being defined and figured that the best way of keeping the spec
clean, was to have a very specific meaning for status, which is just
revocation status.

The issue of whether a cert was ever issued or not, did come up, but
the group concensus was that a client either had the cert in hand and
could verify the signature on the cert and so know whether it was
issued or not.

If the CA's cert signing key was compromised and you wanted to deal
with that case, you need to either directly trust the OCSP responder
and ask it about the CA's self signed cert, or check the CA's cert
if it is part of a larger hierarchy, or try to deal with the issue in
an out of band way.

Hope this helps,
Regards,
Ambarish 

> -----Original Message-----
> From: Simon Tardell [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2000 2:26 AM
> To: 'Ambarish Malpani'; 'Andreas Berger'
> Cc: [email-masked]'
> Subject: RE: German Law and OCSP
> 
> 
> Ambarish wrote:
> 
> >     There are ways of profiling the spec that work within the
> > parameters defined by OCSP. In other ways, you break the design
> > of the basic protocol. In my opinion, this is the latter, not
> > the former.
> 
> The German requirements raise the question what would be the 
> "canonical" way
> of extending OCSP. This is not quite clear to me from reading 
> the RFC. In my
> mind the scope of OCSP is to answer binary status queries on 
> certificates
> (good, bad and possibly "don't know"). The natural question 
> to ask is that
> of revocation. The Germans need to answer that of issuance. 
> Still more can
> be imagined.
> 
> In RFC2560 CertificateStatus can be set to "good", "revoked" 
> or "unknown".
> The wording is a bit unclear here: Does "unknown" mean that 
> "I don't know
> whether this certificate is revoked" or "I know this 
> certificate does not
> exist"? The Germans seem to have opted for the latter 
> interpretation. Now,
> assuming the former interpretation we have three answers to 
> the revocation
> question (good, bad, don't know). How do we extend OCSP to 
> assert the answer
> to other questions? I see two possible approaches:
> 
> 1)
> CertificateStatus is generalized so that it contains the 
> logical sum of all
> properties that the client wants to have asserted (or that 
> the responder
> wants to assert in response to a query). E.g. assume two 
> properties A and B
> that both have to be "good" for a certificate to be valid for 
> use, then
> CertificateStatus is "good" if both of them are "good", "bad" 
> if (at least)
> one of them is "bad" unless one of them is "unknown" in which case
> CertificateStatus is "unknown". Extensions to the respective 
> statuses can be
> used to qualify the answer (e.g. to tell _what_ properties 
> were bad), if the
> client really cares.
> 
> 2)
> CertificateStatus is defined to only provide good, bad and 
> unknown answers
> to the revocation question. SingleExtensions are defined for 
> each property
> (except for revocation status) and each such SingleExtension 
> can take the
> value "good", "bad" and "unknown". The problem then arises 
> that the client
> can perhaps not be expected to understand new properties 
> (extensions) as
> they are implemented on the server. To solve that, these 
> extensions should
> be marked critical if they are "bad" or "unknown", but not if they are
> "good".  
> 
> Now, this is not quite what it says in the RFC (for example, 
> the answer
> "good" allows to be qualified with other types of goodness, 
> but there is
> seemingly no way to answer "not revoked, but bad in some 
> other sense"). The
> former method seems more attractive from the perspective that 
> it allows
> making the clients simpler, but it would require some changes 
> to the current
> protocol. The latter solution would work with current clients 
> (how widely
> deployed are they anyway?) but is less appealing (an error in 
> the client
> would have the meaning "no, you can't do that"...).
> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> [email-masked], http://www.iD2tech.com/
> voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
> European IT-prize grand winners 1998 -- http://www.it-prize.org
> AU-System Group Swedish IT-company of the year 1999
> 

From: Simon Tardell <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Andreas Berger'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Tue, 8 Feb 2000 11:26:28 +0100 

Ambarish wrote:

>     There are ways of profiling the spec that work within the
> parameters defined by OCSP. In other ways, you break the design
> of the basic protocol. In my opinion, this is the latter, not
> the former.

The German requirements raise the question what would be the "canonical" way
of extending OCSP. This is not quite clear to me from reading the RFC. In my
mind the scope of OCSP is to answer binary status queries on certificates
(good, bad and possibly "don't know"). The natural question to ask is that
of revocation. The Germans need to answer that of issuance. Still more can
be imagined.

In RFC2560 CertificateStatus can be set to "good", "revoked" or "unknown".
The wording is a bit unclear here: Does "unknown" mean that "I don't know
whether this certificate is revoked" or "I know this certificate does not
exist"? The Germans seem to have opted for the latter interpretation. Now,
assuming the former interpretation we have three answers to the revocation
question (good, bad, don't know). How do we extend OCSP to assert the answer
to other questions? I see two possible approaches:

1)
CertificateStatus is generalized so that it contains the logical sum of all
properties that the client wants to have asserted (or that the responder
wants to assert in response to a query). E.g. assume two properties A and B
that both have to be "good" for a certificate to be valid for use, then
CertificateStatus is "good" if both of them are "good", "bad" if (at least)
one of them is "bad" unless one of them is "unknown" in which case
CertificateStatus is "unknown". Extensions to the respective statuses can be
used to qualify the answer (e.g. to tell _what_ properties were bad), if the
client really cares.

2)
CertificateStatus is defined to only provide good, bad and unknown answers
to the revocation question. SingleExtensions are defined for each property
(except for revocation status) and each such SingleExtension can take the
value "good", "bad" and "unknown". The problem then arises that the client
can perhaps not be expected to understand new properties (extensions) as
they are implemented on the server. To solve that, these extensions should
be marked critical if they are "bad" or "unknown", but not if they are
"good".  

Now, this is not quite what it says in the RFC (for example, the answer
"good" allows to be qualified with other types of goodness, but there is
seemingly no way to answer "not revoked, but bad in some other sense"). The
former method seems more attractive from the perspective that it allows
making the clients simpler, but it would require some changes to the current
protocol. The latter solution would work with current clients (how widely
deployed are they anyway?) but is less appealing (an error in the client
would have the meaning "no, you can't do that"...).

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

Date: Mon, 07 Feb 2000 12:48:53 -0500
From: Yassir Elley <[email-masked]>
To: [email-masked]
Subject: Question on KeyIdentifier chaining

I have a question about the chaining of SubjectKeyIdentifiers and AuthorityKeyIdentifiers.
Although RFC2459 and the son-of-RFC2459 both RECOMMEND application support
for the authority and subject key identifier extensions, neither document clearly specifies
under what circumstances, if any, should the application reject a certification path based on
invalid key identifier chaining.

The Basic Certificate Processing section very explicitly talks about unique identifier
chaining, but it does not mention key identifier chaining.
About unique identifier chaining, it states:

(5) [Verify that] The certificate issuer unique identifier is the
         working_issuer_UID, meaning:
            (i) working_issuer_UID is non-null and matches the value in
            the issuerUID field, or
            (ii) working_issuer_UID is null and the issuerUID field is
            not present.

I was wondering whether these same rules apply to key identifier chaining.
In other words, should we have a step like:
(6) [Verify that] The certificate authority key identifier is the
         working_AKI, meaning:
            (i) working_AKI is non-null and matches the value in
            the authorityKeyIdentifier field, or
            (ii) working_AKI is null and the authorityKeyIdentifier field is
            not present.

It is unclear to me whether the key identifiers are just meant to FACILITATE
chain building, or whether they are actually meant to be enforced in path validation.
In other words, if an application is presented the following certpath, should the application
reject the cert path because the key identifiers don't chain properly (i.e. Certificate 1
does not have a subject key identifier, but Certificate 2 does have an authority key
identifier)? Alternatively, should the application just treat the key identifiers as hints 
and accept the cert path if  everything else checks out (i.e. the signatures and everything
else, other than the key identifiers, chain properly)?

Certificate 1:
Issuer:     o=verisign,c=us
Subject:    o=sun,c=us
AKI: not present
SKI: not present

Certificate 2:
Issuer:    o=sun,c=us
Subject:  cn=yassir,o=sun,c=us
AKI: present, value=A
SKI: not present

Or what about this chain, where the key identifiers are both present but they don't match?
Should the application reject this chain even though the signatures and everything else,
other than the key identifiers, chain properly.

Certificate 3:
Issuer:     o=verisign,c=us
Subject:    o=sun,c=us
AKI: not present
SKI: present, value=A

Certificate 4:
Issuer:    o=sun,c=us
Subject:  cn=yassir,o=sun,c=us
AKI: present, value=B
SKI: not present

I do realize that Certificate 1 is not a PKIX-conformant since it is a CA certificate
which does not contain a SubjectKeyIdentifier extension, but there may be cases
where certpaths contain both conformant and non-conformant certificates.

Thanks in advance,
Yassir.

Date: Mon, 07 Feb 2000 09:13:43 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Roland Mueller <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>, Robert Zuccherato <[email-masked]>, Mike Matyas <[email-masked]>, Stuart Haber <[email-masked]>, Jean-Jaques Quisquater <[email-masked]>, Xuejia Lai <[email-masked]>, Mike Chawrun <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

> Denis,
> 
> let me clarify our position:
> 
> It is NOT the intention of the ISO working group to introduce patented
> mechanisms, our approach is to allow for MULTIPLE mechanism to be used
> for time stamping. 

Roland,

Since you said that you want multiple mechanisms to be used and that
it is NOT the intention of the ISO working group to introduce
patented mechanisms, would you be able to provide at least one
useful example of such a binding mechanism that is not patented ?

Denis

> That's why we introced a mechanism identifier. This
> ISO draft does NOT suggest the IETF use or endorse any other mechanism,
> it is just for interoperability reasons.
> 
> We are also trying to have common data structures to achieve a common
> base that allows for further extensions (for the IETF and the ISO
> protocols) of time stamping protocols but may be used for schemes as
> already introduced in part 2 of our working draft.
> 
> I hope that this clarifies our requested changes.
> 
> Roland
> 
>   --------------------------------------------------------------------
> 
>   Mueller, Roland <[email-masked]>
>   TUVIT Inc.
> 
>   Mueller, Roland
>   TUVIT Inc.                                            <[email-masked]>
>   8716 North MoPac Suite 220;Austin;Texas;78759;U.S.A.  Télécopie: (512) 795-0495
>                                                         Bureau: (512) 795-0494

Date: Mon, 07 Feb 2000 09:06:06 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Linn, John" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

John, 

Your text addition is fine and I have no problem to add it to the
Security considerations section.

"If different entities obtain timestamps on the same data object
using the same hash algorithm, or a single entity obtains multiple
timestamps on the same object, the generated timestamp tokens will
include identical message imprints; as a result, an observer with
access to those timestamp tokens could infer that the timestamps may
refer to the same underlying data."

Denis
 
> Denis wrote, excerpting:
> 
> > Let us address the three technical points raised by John first:
> >
> > JL1: "If different entities obtain timestamps on the same data
> > object using the same hash algorithm, or a single entity obtains
> > multiple timestamps on the same object, the generated timestamp
> > tokens will include identical message imprints; as a result, an
> > observer could determine that the timestamps refer to the same
> > underlying data.  It might be worth a note in Security
> > Considerations stating that, in contexts where this potential
> > exposure is a concern, some unique value could be generated by the
> > requester and combined with a data object before hashing the
> > combination in order to produce MessageImprint's hashedMessage."
> >
> > An observer could indeed determine that the timestamps refer to the
> > same underlying data. However, this is not a big concern since the
> > observer will neither know the actual content nor the intended
> > usage. The way that is proposed to address this issue might lead to
> > the definition of another standardized binding technique so that the
> > receiver of the TSP can know how to verify the linkage. I am not in
> > favor of defining such a new linkage structure under the reason that
> > I do not find the problem sufficiently important to be corrected. I
> > would rather prefer to address the concern in a different way: if
> > the requester really cares about this problem, he should rather use
> > a protected channel with data confidentiality to access the TSA. If
> > you wish to provide some text along these lines, I would be willing
> > to consider it for inclusion in the security consideration section.
> >
> 
> I don't think that a confidentiality-protected channel to the TSA solves the
> issue I was envisioning.  I expect that some uses of timestamps will require
> that their recipients present or post them (selectively or generally) for
> examination after they're obtained, and that such timestamps could
> potentially be correlated by third parties.  I might be interested, e.g., to
> observe a timestamp obtained by someone else with a hash which matches that
> of a confidential document of mine. I'm not committed to proposing a
> particular mechanism; I suggest, however, slightly adapting text above into
> an advisory note for Security Considerations: "If different entities obtain
> timestamps on the same data object using the same hash algorithm, or a
> single entity obtains multiple timestamps on the same object, the generated
> timestamp tokens will include identical message imprints; as a result, an
> observer with access to those timestamp tokens could infer that the
> timestamps may refer to the same underlying data."
> 
> --jl
> 
>

From: Ambarish Malpani <[email-masked]>
To: "'Mirko Tedaldi'" <[email-masked]>, Ilan Shacham <[email-masked]>
Cc: [email-masked]
Subject: RE: OCSP and CSL
Date: Sat, 5 Feb 2000 12:02:33 -0800 

Hi Mirko,
    Most commercial software does not remove expired, revoked
certs from their CRLs, but there have already been requests
for that behavior. Expect to see it in CA products this year.

Regards,
Ambarish

> -----Original Message-----
> From: Mirko Tedaldi [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2000 6:36 AM
> To: Ilan Shacham
> Cc: [email-masked]
> Subject: RE: OCSP and CSL
> 
> 
> At 14.30 02/02/00 +0200, Ilan Shacham wrote:
> 
> >Section 3.3 of RFC 2459 clearly states:
> >         An entry may be removed from
> >    the CRL after appearing on one regularly scheduled CRL 
> issued beyond
> >    the revoked certificate's validity period.
> >
> >If you want to validate an "old" signature, all you have to do is
> >retrive the crl that was in order at the time of the signature, to
> >see if the certificate was valid at the time.
> 
> About it, do you know how commercial PKI softwares work? Do 
> they remove 
> expired certificates from CRL ?
> 
> Mirko Tedaldi.
> 

From: Ambarish Malpani <[email-masked]>
To: "'Joerg Seidel'" <[email-masked]>, Massimiliano Pala <[email-masked]>
Cc: [email-masked]
Subject: RE: OCSP and CSL
Date: Sat, 5 Feb 2000 11:48:03 -0800 

Hi Joerg,
    No, this isn't a security flaw - PKIX requires a revoked
cert to appear in at least 1 CRL before it is dropped of the
CRL list because of expiry - somebody already thought of
this one!

Regards,
Ambarish

> -----Original Message-----
> From: Joerg Seidel [mailto:[email-masked]]
> Sent: Thursday, February 03, 2000 5:12 AM
> To: Massimiliano Pala
> Cc: [email-masked]
> Subject: Re: OCSP and CSL
> 
> 
> Massimiliano Pala schrieb:
> > 
> > Irene Gassko wrote:
> > >
> > > >2. once a cert is inserted into a CRL, it can *never* be
> > > >deleted from it
> > >
> > > This is not true. Expired certificates are deleted from CRL.
> > 
> > I am not sure about this. If you delete it from the list how you can
> > prove it is not valid from the revokation date on ??? The 
> CRLs should
> > provide an 'history' of all revoked certificates...
> 
> In order to prove the invalidity of a certain signature you 
> need the CRL of
> the point of time the signature was made. Well, more 
> precisely the CRL which
> was released next after the signature was made. If you want 
> to be able to
> prove the validity of a signature after the expiration date of the
> corresponding certificate you need to store this CRL together with the
> signature. Well and you need to prove the validity of the
> CRL-Signing-Certificate at that time, so you need ... and so 
> on until you are
> got a CRL signed with a private key corresponding to a non-expired and
> non-revoked certificate.
> 
> I just realized: Maybe there is a small security flaw in this 
> system: If a
> certificate gets revoked just before certificate expiration, 
> but the next CRL
> is released after the expiration time, the revocation might 
> not been stated in
> CRLs at all. The state of the signature is unknown.
> 
> Jörg Seidel
> -- 
> timeproof                               phone  +49-40-76629-1911
> Development                             fax    +49-40-76629-551
> Harburger Schloßstraße 6-12             mailto:[email-masked]
> D-21079 Hamburg                         http://www.timeproof.de
> 
>      + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +
> 

Date: Fri, 04 Feb 2000 15:47:57 -0600
From: Roland Mueller <[email-masked]>
Organization: TUVIT Inc.
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>, Robert Zuccherato <[email-masked]>, Mike Matyas <[email-masked]>, Stuart Haber <[email-masked]>, Jean-Jaques Quisquater <[email-masked]>, Xuejia Lai <[email-masked]>, Mike Chawrun <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

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

Denis,

let me clarify our position:

It is NOT the intention of the ISO working group to introduce patented
mechanisms, our approach is to allow for MULTIPLE mechanism to be used
for time stamping. That's why we introced a mechanism identifier. This
ISO draft does NOT suggest the IETF use or endorse any other mechanism,
it is just for interoperability reasons.

We are also trying to have common data structures to achieve a common
base that allows for further extensions (for the IETF and the ISO
protocols) of time stamping protocols but may be used for schemes as
already introduced in part 2 of our working draft.

I hope that this clarifies our requested changes.

Roland
--------------6E20372CE9B681C67E22FE5F
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:(512) 795-0495
tel;work:(512) 795-0494
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------6E20372CE9B681C67E22FE5F--

Date: Fri, 04 Feb 2000 09:17:57 -0800
From: [email-masked] (Terry Hayes)
To: "Linn John" <[email-masked]>
CC: "'Denis Pinkas'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

Reguarding the security concerns around identical MessageImprint values:

I agree that text describing this issue would be useful.  While the problem will
not be a concern for many who use this protocol, describing the it in the
Security Considerations section will keep at least one implementor from creating
an application that does not provide the desired security.

You might also consider suggesting a way to address the problem in particular
applications.  Creating the MessageImprint from data that contains a salt value,
and the original document nicely avoids this problem.  This type of solution can
be implemented by applications that require it.  There is no need to add it to
the timestamping protocol.

Terry

"Linn, John" wrote:

> Denis wrote, excerpting:
>
> > Let us address the three technical points raised by John first:
> >
> > JL1: "If different entities obtain timestamps on the same data
> > object using the same hash algorithm, or a single entity obtains
> > multiple timestamps on the same object, the generated timestamp
> > tokens will include identical message imprints; as a result, an
> > observer could determine that the timestamps refer to the same
> > underlying data.  It might be worth a note in Security
> > Considerations stating that, in contexts where this potential
> > exposure is a concern, some unique value could be generated by the
> > requester and combined with a data object before hashing the
> > combination in order to produce MessageImprint's hashedMessage."
> >
> > An observer could indeed determine that the timestamps refer to the
> > same underlying data. However, this is not a big concern since the
> > observer will neither know the actual content nor the intended
> > usage. The way that is proposed to address this issue might lead to
> > the definition of another standardized binding technique so that the
> > receiver of the TSP can know how to verify the linkage. I am not in
> > favor of defining such a new linkage structure under the reason that
> > I do not find the problem sufficiently important to be corrected. I
> > would rather prefer to address the concern in a different way: if
> > the requester really cares about this problem, he should rather use
> > a protected channel with data confidentiality to access the TSA. If
> > you wish to provide some text along these lines, I would be willing
> > to consider it for inclusion in the security consideration section.
> >
>
> I don't think that a confidentiality-protected channel to the TSA solves the
> issue I was envisioning.  I expect that some uses of timestamps will require
> that their recipients present or post them (selectively or generally) for
> examination after they're obtained, and that such timestamps could
> potentially be correlated by third parties.  I might be interested, e.g., to
> observe a timestamp obtained by someone else with a hash which matches that
> of a confidential document of mine. I'm not committed to proposing a
> particular mechanism; I suggest, however, slightly adapting text above into
> an advisory note for Security Considerations: "If different entities obtain
> timestamps on the same data object using the same hash algorithm, or a
> single entity obtains multiple timestamps on the same object, the generated
> timestamp tokens will include identical message imprints; as a result, an
> observer with access to those timestamp tokens could infer that the
> timestamps may refer to the same underlying data."
>
> --jl
>
>

Date: Fri, 4 Feb 2000 10:48:21 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

>>>>> "Joerg" == Joerg Seidel <[email-masked]> writes:

 Joerg> "Linn, John" schrieb:
 >> I don't think that a confidentiality-protected channel to the TSA
 >> solves the issue I was envisioning.  I expect that some uses of
 >> timestamps will require that their recipients present or post them
 >> (selectively or generally) for examination after they're obtained,
 >> and that such timestamps could potentially be correlated by third
 >> parties.  I might be interested, e.g., to observe a timestamp
 >> obtained by someone else with a hash which matches that of a
 >> confidential document of mine.
 Joerg> I don't think that this really matters in pratical life, since
 Joerg> a timestamp without the corresponding document wouldn't proof
 Joerg> anything. I can not imagine an application which makes it
 Joerg> necessary to send a timestamp without the document.

I suppose it isn't entirely obvious what sort of hazards are created
by the scenarion John mentioned.  On the other hand, it is clear that
what John described is accurate: if you have two timestamps with the
same imprint, the conclusion that they are for the same document
follows automatically.

Consider the analogy of ECB encryption -- this is considered unwise
because of the property that the occurrence of the same cipher block
means the same plaintext was encrypted.  Does that matter?  Often, it
doesn't.  Sometimes it might.  Since it's trivially avoided (by using
any other mode), ECB is considered a thing to avoid.

While one might argue about the importance of adding the note John
asked for, is there harm in adding it?  Does it mislead?  I don't see
that it does.  It provides information that may only matter to a very
few, but since it does, let's add it.

	paul

Date: Fri, 4 Feb 2000 10:42:14 -0500
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

>>>>> "Linn," == Linn, John <[email-masked]> writes:

 Linn,> I don't think that a confidentiality-protected channel to the
 Linn,> TSA solves the issue I was envisioning.  I expect that some
 Linn,> uses of timestamps will require that their recipients present
 Linn,> or post them (selectively or generally) for examination after
 Linn,> they're obtained, and that such timestamps could potentially
 Linn,> be correlated by third parties.  I might be interested, e.g.,
 Linn,> to observe a timestamp obtained by someone else with a hash
 Linn,> which matches that of a confidential document of mine. I'm not
 Linn,> committed to proposing a particular mechanism; I suggest,
 Linn,> however, slightly adapting text above into an advisory note
 Linn,> for Security Considerations: "If different entities obtain
 Linn,> timestamps on the same data object using the same hash
 Linn,> algorithm, or a single entity obtains multiple timestamps on
 Linn,> the same object, the generated timestamp tokens will include
 Linn,> identical message imprints; as a result, an observer with
 Linn,> access to those timestamp tokens could infer that the
 Linn,> timestamps may refer to the same underlying data."

I support John's reasoning.  The proposed note sounds good.  (I'd
suggest dropping "may" from the last line, since the hash is supposed
to have low probability of collisions.)

	paul

Date: Fri, 04 Feb 2000 15:53:08 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: "Linn, John" <[email-masked]>
CC: "'Denis Pinkas'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

"Linn, John" schrieb:
> I don't think that a confidentiality-protected channel to the TSA solves the
> issue I was envisioning.  I expect that some uses of timestamps will require
> that their recipients present or post them (selectively or generally) for
> examination after they're obtained, and that such timestamps could
> potentially be correlated by third parties.  I might be interested, e.g., to
> observe a timestamp obtained by someone else with a hash which matches that
> of a confidential document of mine.
I don't think that this really matters in pratical life, since a timestamp
without the corresponding document wouldn't proof anything. I can not imagine
an application which makes it necessary to send a timestamp without the
document. But if you are transmitting/publishing the document together with
the timestamp, the third party would be looking for the document not the hash
since it can even recognize it when small changes were made.

> I'm not committed to proposing a
> particular mechanism; I suggest, however, slightly adapting text above into
> an advisory note for Security Considerations: "If different entities obtain
> timestamps on the same data object using the same hash algorithm, or a
> single entity obtains multiple timestamps on the same object, the generated
> timestamp tokens will include identical message imprints; as a result, an
> observer with access to those timestamp tokens could infer that the
> timestamps may refer to the same underlying data."
As stated above I do not believe this to be necessary, but I don't have an
objection either.

Jörg Seidel

-- 
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +

From: "Linn, John" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Date: Fri, 4 Feb 2000 09:20:27 -0500 

Denis wrote, excerpting:

> Let us address the three technical points raised by John first:
> 
> JL1: "If different entities obtain timestamps on the same data
> object using the same hash algorithm, or a single entity obtains
> multiple timestamps on the same object, the generated timestamp
> tokens will include identical message imprints; as a result, an
> observer could determine that the timestamps refer to the same
> underlying data.  It might be worth a note in Security
> Considerations stating that, in contexts where this potential
> exposure is a concern, some unique value could be generated by the
> requester and combined with a data object before hashing the
> combination in order to produce MessageImprint's hashedMessage."
> 
> An observer could indeed determine that the timestamps refer to the
> same underlying data. However, this is not a big concern since the
> observer will neither know the actual content nor the intended
> usage. The way that is proposed to address this issue might lead to
> the definition of another standardized binding technique so that the
> receiver of the TSP can know how to verify the linkage. I am not in
> favor of defining such a new linkage structure under the reason that
> I do not find the problem sufficiently important to be corrected. I
> would rather prefer to address the concern in a different way: if
> the requester really cares about this problem, he should rather use
> a protected channel with data confidentiality to access the TSA. If
> you wish to provide some text along these lines, I would be willing
> to consider it for inclusion in the security consideration section.
> 

I don't think that a confidentiality-protected channel to the TSA solves the
issue I was envisioning.  I expect that some uses of timestamps will require
that their recipients present or post them (selectively or generally) for
examination after they're obtained, and that such timestamps could
potentially be correlated by third parties.  I might be interested, e.g., to
observe a timestamp obtained by someone else with a hash which matches that
of a confidential document of mine. I'm not committed to proposing a
particular mechanism; I suggest, however, slightly adapting text above into
an advisory note for Security Considerations: "If different entities obtain
timestamps on the same data object using the same hash algorithm, or a
single entity obtains multiple timestamps on the same object, the generated
timestamp tokens will include identical message imprints; as a result, an
observer with access to those timestamp tokens could infer that the
timestamps may refer to the same underlying data."

--jl

Date: Fri, 4 Feb 2000 11:59:11 +0100
To: [email-masked]
From: Mats Hansson <[email-masked]>
Subject: Comment on RFC 2459: Validity time type

Dear Sirs,

I have a comment on clause 4.1.2.5: "Validity" in the RFC 2459. Most
probably, you have already had similar comments, but anyway:

Why is it not allowed to use the GeneralizedTime format for validity dates
before 2050? Why not use the next 50 years gradually allowing and
encouraging CA's and clients to switch over to a time format more suitable
for the future? The present spec. preserves the two-digit limitation and it
is not until some years before 2050 that PKI/security software will get the
real test that they are treating the four-digit representation properly.
Will we see a "close-to-2050"-bug then, all over the world, just like the
millenium-bug?

My suggestion is to allow the GeneralizedTime type now already. Or at least
start allowing it after a known date, say year 2005. So software will have a
chance to be modified. Sooner or later, we (programmers) will face the
"real" test.

Kindest regards
Mats Hansson

Mats Hansson
Intertex Data AB
Rissneleden 45
174 44 Sundbyberg
Sweden

Tel +46-8-6282828    Fax +46-8-6286414    www: http://www.intertex.se

Date: Fri, 04 Feb 2000 11:31:57 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "[email-masked]'" <[email-masked]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

On January the 25 th Warwick Ford, co-chair of the PKIX WG, issued a
14-days WG Last Call on the document
draft-ietf-pkix-time-stamp-05.txt.

The last call period will thus end on February the 8 th.

Up to now, several comments and responses have been posted to the
mailing list by Roland Mueller, Michael Zolotarev, Magnus Nystrom,
Peter Gutmann, Paul Koning, John Linn and Philip Hallam-Baker.

As lead editor of the document I will attempt to summarize the
comments that have been received so far.

Roland, as editor of an ISO document on time stamping (WD 18014) is
asking for an extremely late and major change in the document. The
rational advocated for that change request is to accommodate
particular mechanisms that do not use digital signatures.

Paul asked for an example to justify added stuff and Roland produced
a 5 pages text, ... which did not convinced Paul for making the
change. Roland did not replied up to now.

John raised three technical comments (I will answer to them later
below) and pointed a few editorial errors (thanks John !).

Philip discussed on the first technical points raised by John.

Peter asked for the removal of some ASN1 tags. Magnus supported this
position.

Let us address the three technical points raised by John first:

JL1: "If different entities obtain timestamps on the same data
object using the same hash algorithm, or a single entity obtains
multiple timestamps on the same object, the generated timestamp
tokens will include identical message imprints; as a result, an
observer could determine that the timestamps refer to the same
underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential
exposure is a concern, some unique value could be generated by the
requester and combined with a data object before hashing the
combination in order to produce MessageImprint's hashedMessage."

An observer could indeed determine that the timestamps refer to the
same underlying data. However, this is not a big concern since the
observer will neither know the actual content nor the intended
usage. The way that is proposed to address this issue might lead to
the definition of another standardized binding technique so that the
receiver of the TSP can know how to verify the linkage. I am not in
favor of defining such a new linkage structure under the reason that
I do not find the problem sufficiently important to be corrected. I
would rather prefer to address the concern in a different way: if
the requester really cares about this problem, he should rather use
a protected channel with data confidentiality to access the TSA. If
you wish to provide some text along these lines, I would be willing
to consider it for inclusion in the security consideration section.

JL2: "The second paragraph of Sec. 2.2 bears a number of SHALLs for
verification steps which are to be performed by the requesting
entity once the TimeStampToken is received.  What's the recommended
or required action if any of these verifications fail? "

Here is the text:

Upon receiving the response (which is or includes a TimeStampResp,
as defined below), the requesting entity SHALL verify the status
error 
returned in the response and if no error is present it SHALL verify
the
various fields contained in the TimeStampToken and the validity of
the 
digital signature of the TimeStampToken. In particular, it SHALL
verify
that what was time stamped corresponds to what was requested to be 
time stamped.  The requester SHALL verify that the TimeStampToken
contains the correct certificate identifier of the TSA, the correct 
data imprint and the correct hash algorithm OID.  It SHALL then
verify 
the timeliness of the response by verifying either the time included 
in the response against a local trusted time reference, if one is 
available, and/or the value of the nonce (large random number with a 
high probability that it is generated by the client only once) 
included in the response against the value included in the request.

I propose to add: "If any of the verifications above fails, the
TimeStampToken SHALL be rejected."

JL3: "In the Accuracy structure, is no more than one of the seconds,
millis, or micros OPTIONALs to occur, or may more than one of these
elements occur in combination? "

If you want to express, e.g. 1,5 s you have to use two of them in
combination. However, I suspect that in practice this case will be
quite seldom, but in theory any value must be able to be expressed.

Now let us come back to the main issue raised by Roland. Since, I
have shown up in an ISO ad-hoc meeting on Time Stamping that was
held on the last day of the RSA conference in San Jose, I know a
little bit more than what has been exposed.

I will wear two hats in sequence:

1) to express my own opinion,
2) to act as a moderator in the discussion.

My own opinion first: 

I cannot agree more with Roland when he says: " It is understood
that this proposal reaches the IETF working group at an extremely
late stage in its standardisation cycle." 

The main idea seems to open the door to "binding schemes" that do
not use digital signatures. The single one that I know is the
patented scheme from Surety. It has been advocated that other
schemes could also fall under that umbrella, but, up to now, no one
has yet advertised an unpatented scheme. It would thus seem that the
motivation of the change is to allow similar ASN1 structures to be
used for content of the Time Stamp Token, whatever binding scheme is
being used; in practice, the (unpatended) scheme from the PKIX WG
and at least one patented scheme from Surety.

My position as a moderator:

I am awaiting for other comments or opinions on that topic before
trying to see where the WG concensus is.

Denis.

From: Ambarish Malpani <[email-masked]>
To: "'Andreas Berger'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: German Law and OCSP
Date: Thu, 3 Feb 2000 11:05:17 -0800 

Hi Andreas,
    Does it really make sense calling this OCSP any more? You will
most probably not work with most of the servers/clients.

    Also, you do have the requirement that the client verifies the
public key hash that it receives in the response...

    There are ways of profiling the spec that work within the
parameters defined by OCSP. In other ways, you break the design
of the basic protocol. In my opinion, this is the latter, not
the former.

Regards,
Ambarish

P.S. If you can get the German standard changed to follow the
spec, that might not be a very bad idea.

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

> -----Original Message-----
> From: Andreas Berger [mailto:[email-masked]]
> Sent: Monday, January 31, 2000 5:19 AM
> To: Ambarish Malpani
> Cc: [email-masked]'
> Subject: Re: German Law and OCSP
> 
> 
> Ambarish Malpani wrote:
> > 
> > Hi Guys,
> >     I recently read a document that seemed to indicate that
> > the German Digital Signature Law or some related documents
> > specified that you can use OCSP to check the revocation status
> > of a cert, but they allowed you to send over all 0's as the
> > hash of the CA's public key.
> 
> This is true. We introduced this option to enable the 
> end-system to make
> queries about certificates when the CA certificate is not (at least at
> the point of this check) known. Therefore, we allowed to "omit" the CA
> public key (resp. the hash) in the query. The hash is, of course,
> required in the reply.
> 
> >     Does anybody know more about whether the statement above
> > is true or not? If it is, I am concened that they might not be
> > using OCSP correctly.
> 
> We had to extend the functionality (it was mid 1998 if I remember
> correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
> design. We needed (as Hans has written)
> 
> 1. Certificate was created, is in the service since T, and is not
> revoked
> 2. Certificate was created, is in the service since T, and is revoked
> 3. Certificate is unknown
> 
> which was not possible with then the OCSP.
> 
> Andreas Berger
> GMD Darmstadt
> -- 
> Keine Zeit haben wir genug!
> 

From: [email-masked]
Subject: Latest Jonah code now available
To: [email-masked], [email-masked]
Date: Thu, 3 Feb 2000 12:38:37 -0500

     The latest snapshot of the Jonah code is available from
http://www.foobar.com/jonah.
     This code should also be available from http://web.mit.edu/pfl soon.
This release is
     available internationally.

     Jonah is a open source implementation written by IBM and its
subsidiaries Lotus and Iris.
     It currently implements a subset of the IETF PKIX standards (
RFC-2459, RFC-2510,
     RFC-2511, and RFC-2587).

     There was a paper published in the 8th USENIX Security Symposium
Proceedings
     on Jonah. A copy of the paper can be found at
http://www.foobar.com/papers/usenix-jonah.html.

     Discussion of Jonah takes place on the [email-masked] mailing list.
An archive of this list
     can be found at http://www.imc.org/imc-pfl.

     This code should not be considered a complete work, although it is the
last major
     drop that we plan on doing. Some of the code has gotten a lot more
attention then
     others. For example, the GUI has fallen behind some of the other
pieces of code.
     We hope that this becomes a community effort to help maintain this
code, and
     people well supply  comments, bug fixes, and new features.

                              Mike

From: "Robert Rowland" <[email-masked]>
To: "Joerg Seidel" <[email-masked]>, "Massimiliano Pala" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP and CSL
Date: Thu, 3 Feb 2000 09:03:11 -0800
Importance: Normal

Is it possible that these problems be divided into two different needs:
1) real time authentication-> vpn technologies,
2) long term authentication->wills, contracts,....

The need for verification of valid certs three years ago sems moot if the
purpose is/was used for corporate remote dial-in,
versus the need to assure that my signature on my will is not used to give
Anna Nicole
Smith any more money.

?????

-----Original Message-----
From: Joerg Seidel [mailto:[email-masked]]
Sent: Thursday, February 03, 2000 5:12 AM
To: Massimiliano Pala
Cc: [email-masked]
Subject: Re: OCSP and CSL

Massimiliano Pala schrieb:
>
> Irene Gassko wrote:
> >
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> >
> > This is not true. Expired certificates are deleted from CRL.
>
> I am not sure about this. If you delete it from the list how you can
> prove it is not valid from the revokation date on ??? The CRLs should
> provide an 'history' of all revoked certificates...

In order to prove the invalidity of a certain signature you need the CRL
of
the point of time the signature was made. Well, more precisely the CRL
which
was released next after the signature was made. If you want to be able
to
prove the validity of a signature after the expiration date of the
corresponding certificate you need to store this CRL together with the
signature. Well and you need to prove the validity of the
CRL-Signing-Certificate at that time, so you need ... and so on until
you are
got a CRL signed with a private key corresponding to a non-expired and
non-revoked certificate.

I just realized: Maybe there is a small security flaw in this system: If
a
certificate gets revoked just before certificate expiration, but the
next CRL
is released after the expiration time, the revocation might not been
stated in
CRLs at all. The state of the signature is unknown.

Jörg Seidel
--
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +

From: "Duncan Deborde" <[email-masked]>
Sender: "Duncan Deborde" <[email-masked]>
To: Joerg Seidel <[email-masked]>
Cc: [email-masked]
Date: Thu, 3 Feb 2000 13:57:05 +0000
Subject: Re: OCSP and CSL

Jörg Seidel wrote

> I just realized: Maybe there is a small security flaw in this system: If a
> certificate gets revoked just before certificate expiration, but the next CRL
> is released after the expiration time, the revocation might not been stated in
> CRLs at all. The state of the signature is unknown.

RFC2459 states: "An entry may be removed from  the CRL after appearing on one
regularly scheduled CRL issued beyond the revoked certificate's validity
period."

Assuming this implies the entry must be present for the next CRL after the
expiration time, this situation you propose will not arise.

Duncan de Borde

Date: Thu, 03 Feb 2000 15:25:43 +0100
To: Joerg Seidel <[email-masked]>
From: Mirko Tedaldi <[email-masked]>
Subject: Re: OCSP and CSL
Cc: [email-masked]

At 14.12 03/02/00 +0100, Joerg Seidel wrote:
>I just realized: Maybe there is a small security flaw in this system: If a
>certificate gets revoked just before certificate expiration, but the next CRL
>is released after the expiration time, the revocation might not been stated in
>CRLs at all. The state of the signature is unknown.

I don't think it is a flaw. A revoked certificate must be always issued in 
CRLs, even if it is expired at the moment of issuing CRL. Actually, RFC 
2459 states that a exipired certificate may be removed just "after 
appearing on one regularly scheduled CRL."

Mirko Tedaldi.

Date: Thu, 03 Feb 2000 14:12:22 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof
To: Massimiliano Pala <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP and CSL

Massimiliano Pala schrieb:
> 
> Irene Gassko wrote:
> >
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> >
> > This is not true. Expired certificates are deleted from CRL.
> 
> I am not sure about this. If you delete it from the list how you can
> prove it is not valid from the revokation date on ??? The CRLs should
> provide an 'history' of all revoked certificates...

In order to prove the invalidity of a certain signature you need the CRL of
the point of time the signature was made. Well, more precisely the CRL which
was released next after the signature was made. If you want to be able to
prove the validity of a signature after the expiration date of the
corresponding certificate you need to store this CRL together with the
signature. Well and you need to prove the validity of the
CRL-Signing-Certificate at that time, so you need ... and so on until you are
got a CRL signed with a private key corresponding to a non-expired and
non-revoked certificate.

I just realized: Maybe there is a small security flaw in this system: If a
certificate gets revoked just before certificate expiration, but the next CRL
is released after the expiration time, the revocation might not been stated in
CRLs at all. The state of the signature is unknown.

Jörg Seidel
-- 
timeproof                               phone  +49-40-76629-1911
Development                             fax    +49-40-76629-551
Harburger Schloßstraße 6-12             mailto:[email-masked]
D-21079 Hamburg                         http://www.timeproof.de

     + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +

From: Simon Tardell <[email-masked]>
To: "'Massimiliano Pala'" <[email-masked]>
Cc: [email-masked]
Subject: RE: More on OCSP and CSL
Date: Thu, 3 Feb 2000 13:59:04 +0100 

> Antonio Lioy wrote:
>  
> > This is another view: the CSL is being used as a waiting
> > list for possibly revoked certs. If it is later revoked,
> > then you'll put it in the CRL, otherwise you'll remove it
> > from the CSL.
> > 
> > But I disagree with this view: if I temporarily lost control
> > of my smart-card, I can never know what has happened during
> > that period of time.
> 
> Yes, but I think that if you are not sure about some misusage
> of the private key, then you should request it to be revoked.
> 
> This is for two reasons: the first is about how long a CSL will
> become if we keep track about every suspension of certificates
> and the second is about your trusting in your key-pair.

> If we keep every suspension tracked on the CSL, it can get a
> very long list and it could suffer from problems related to
> this aspect (distribution, definition of delta's CSL, and so
> on... ). I'd like to avoid these problems as them tend to
> get the CSL more complex than needed.

Your CSLs will of course suffer from the same problems as CRLs but worse.
However this is only a problem if regularly transfer all of the list (CSL or
CRL) from a CA somewhere. 

The whole idea of having a _periodically_ updated list of the current status
of the database of the CA is to me a rather ridiculous attempt of modelling
an old technology solution to a problem using new technology, NOT solving
the problem with the new technology. (The old technology solution is of
course the printed books that merchants used to check your card against.)
Serializations of the database are needed when you need to transport all of
the data from the CA to somewhere, e.g. to startup the cache of a validation
authority -- other certificate status consumers should only care about the
status of the certificates involved in the operation they are about to
perform (that's why we have OCSP).

Finally, I do realize that issuing CRLs periodically is convenient from an
implementor's perspective (because that's what I am), but following the
arguments above I think it is unhealthy to mandate that nextUpdate _always_
be set in a CRL (like RFC2459 does).
 
> The second aspect is related on the fact that if you do not
> trust your key for a certain period, than you should not trust
> it at all because it could be open to every kind of attacks:
> let's say someone discovers your password and uses it non only
> when it is suspended, but he/her can get in touch with your key
> during the working time when you are having a coffe-break...
> 
> If you are now trusting your key it is possible you think that
> the 5 mins of a coffe break do not represent a real danger...
> 
> So my vision is: if you trust your certificate is because it has
> never been in danger, if there is a possibility your certificate
> (read key-pair) has been compromised (so it con be compromised
> again...) either if you are not sure about it, than you should
> revoke it...
[...]
> Once a key/pair has been compromised (or possibily compromised)
> it should not, to me, being trusted any more.

Well, if you have a smart card the idea is that your typical office pick
pocket, teenage son or whatever is the most common wallet poacher type, does
not have access to a tunneling microscope or some other equipment to extract
the keys from the card. So, it would suffice to change PIN code of the card
once you regain physical possession of the card to be able to trust the keys
from that moment on.

If you allow reestablishing trust in a smart card token that way or not is
again a policy question. But given the manufacturing cost of a smart card, I
think it is not unlikely that some CAs would.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
[email-masked], http://www.iD2tech.com/
voice +46 8 7755225, cell +46 70 3198319, fax +46 8 7267912
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999

Sender: [email-masked]
Date: Thu, 03 Feb 2000 13:34:58 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Comune di Modena
To: Irene Gassko <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP and CSL

This is a cryptographically signed message in MIME format.

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

Irene Gassko wrote:
> 
> At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
> >Juan Rodriguez-Torrent wrote:
> >[snip]
> >I'm mildly unsatisfied of the recent discussion over this
> >list. It appears that everybody is against certificate
> >suspension, given its associated cost. I think that, when
> >speaking technically, we should abide from the associated
> >costs of operation, because those costs are quite sensitive
> >to the perceived needs from the users (otherwise we would
> >never define or adopt strong security measures because they
> >are surely too expensive :-)
> >Moreover, some mails suggest to use CRL with the OnHold
> >reason for suspension, and later remove the certificate if
> >it is not actually revoked. What??? I have some really bad
> >feeling about this solution because my understanding is:
> >1. "revoked" means revoked, i.e. the cert is no more valid
> >for any use starting from a certain date
> 
> If we look for a real world analogy here, I would expect that it
> would be instructive to see how credit card companies handle it.
> Most will close your account forever, but when I called AMEX
> and asked them to close my account, they told me that within
> a year I could reopen it if I changed my mind. Hence this is at
> least debatable.
> 
> >2. once a cert is inserted into a CRL, it can *never* be
> >deleted from it
> 
> This is not true. Expired certificates are deleted from CRL.

I am not sure about this. If you delete it from the list how you can
prove it is not valid from the revokation date on ??? The CRLs should
provide an 'history' of all revoked certificates...

C'you,

	Massimiliano Pala ([email-masked])
--------------msF9DEB266365B773EC75AB37B
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

--------------msF9DEB266365B773EC75AB37B--

Sender: [email-masked]
Date: Thu, 03 Feb 2000 11:44:13 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Comune di Modena
To: Juan Rodriguez-Torrent <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP and CSL

This is a cryptographically signed message in MIME format.

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

Juan Rodriguez-Torrent wrote:
> 
> So on Friday I "suspend" my cert ... how do I do that? signing with the cert
> I want to suspend? calling a help desk ($$)? ... and then on Monday how do I
> activate my cert? Another phone call ($$)? signing a request with the
> suspended cert? Oh! I forgot the one time token! But who would trust that
> "one time token" left on an insecure office next to the vacationing certs? I
> claim it would have no trust associated... unless I carry it with me and
> then why not carry the original cert that I'm trying to suspend and avoid
> all the hassle? Maybe I should get an additional cert so I can suspend and
> activate the one cert I want to leave in my office during the weekend? Does
> any of this makes any business sense?

The mechanisms of supension/revoking/re-validation are up to the organization:
some organizations could simply require a signed form to suspend the certificate
and/or using an additional code given to the user at the issuing time, others
could accept it on the phone... etc... I think this is something related to
organizations' policy.

On the certificate suspension/re-validation: if the user trusts again the
certificate (see my previous today mails) than he/she can ask for re-validation,
if this is not the case (he/she do not trust is) the revokation is requested.
I think it is up to the user (or you can simply decide to use the suspension
mechanism when someone asks for revokation to avoid time delays between
the request and the real revokation).

> The smart card example is another example on how we are so desperately
> trying to change business processes that actually work. Does anyone leave
> their passport, driver license, credit card or checkbook in and untrusted
> area for a weekend?

I usually don't. But what if you loose it ?? Or simply you can not remember
where it is ??? We should consider these cases either...
 
> Have you considered the costs of involved in this "let's give our certs the
> week-end off"? In a large office hiring certsitting personnel could be much
> cheaper than all those convoluted motions I see proposed for trivial
> reasons. No one in their right state of mind leaves the ATM card, credit
> card or any financial relevant document seating in an insecure office over
> the weekend for the pleasure of it.

You should trust the certificate-sitters ... and what if them sign contracts for
$millions??? You do not have any mechanism to state you were not using it (not
everyone uses smartcards, I think the majority of certificates are simply stored
on removable medias (floppy, CD, Zip, etc... ) as smartcards are not so widely
available... not everywhere at least).

C'you,

	Massimiliano Pala ([email-masked])
--------------ms5ACAEAB8B9A96F71546AFBEF
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

--------------ms5ACAEAB8B9A96F71546AFBEF--

Sender: [email-masked]
Date: Thu, 03 Feb 2000 11:22:27 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Comune di Modena
To: Juan Rodriguez-Torrent <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP and CSL

This is a cryptographically signed message in MIME format.

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

Juan Rodriguez-Torrent wrote:
> 
> Massimiliano, the issue of suspension was discussed several times during the
> last few years and the bottom line is that nobody was able to show a
> reasonable business case for it. In other words, there is not enough
> interest in suspension mechanisms to generate income or help sales of a
> specific PKI because of that feature. I'm sure the additional complexity
> that Russ brings to our attention would be less of a deterrent if someone
> was willing to make suspension mechanisms attractive to the vendors. Let's
> not forget the ISVs (Independent Software Vendors) that have to add yet
> another level of complexity to their products to enable suspension and they
> also have to be convinced. Also, let's not forget the additional complexity
> to be stated on the policies with the corresponding legal issues arising
> from that added feature.  I could go on for a while on that subject but I
> think you got my point.

I know, adding complexity is never a feature... at least when that complexity is
not needed. My thinking about it are very clear... we need something to provide
such service ...

> Let me add that the reason you stated for having a certificate suspension
> list is trivial and raises fundamental questions:
> 
> 1. If the CA is offline WHO WOULD create the suspension list?

The OCSP server could do that as it is a trusted suorce of information and it
have to keep track of the 'validity' of the certificates. So you can retrieve
the certificate status by getting the OCSP response about it, or just get the
CSL/CRL pair in this case you'll know exaclty wich certificates are suspended
and/or revoked).

> 2. Since without a trusted authority a suspension list will be worthless,
> why bother? It appears that the only reason for having a suspension list is
> because the CA is offline and want to avoid bringing the CA online to issue
> a CRL but the suspension lists needs to be issued by the CA ... (?)

You NEVER bring your CA on-line... the CSL indeed is not issued by the CA itself
as it is needed to provide a new CSL when a user asks for its suspension...
he CSL issuing should be tied to an on-line authority (as described at point
1).
 
> 3. Also why do you think that offline CAs are any different than CAs that
> only issue CRLs at fixed time intervals (i.e. every 8 hours, every hour or
> every minute). There will always be a time gap between CRL instances,
> independently if the CA is online or not, and that's were policies -of
> relaying parties, CAs, etc.- have a role.

CSLs are not CRLs... when the user asks for a suspension the status gets to
suspended in a metter of seconds (or less). This suspends the certificates
immediately and if the certificate will get revoked then track of this suspension
will be held and if some misusage of the certificate arise than you can prove
that should not be trusted as an authorized usage because it was suspended.

> If your environment needs a high level of responsiveness, a more reasonable
> approach is to solve the problems you did not state (e.g. why the CA has to
> be offline?) and bring your CA on-line using mechanisms and protocols
> appropriate for the application. Trying to develop new protocols to solve an
> apparently trivial environment/operations issue adds, as stated above,
> complexity and also interoperability issues to an already complex and less
> that interoperable environment.
> 

To me the only way of being sure about avoiding network attacks is to have the
CA disconnected from ANY network (being it internal to the organization only or not)
and this to provide an high security profile... This causes the problems related
to the suspension/revoking of certificates and time delays between the request
being received and the real revoking time of the certificate. If you are not
using this CA model than you do not suffer of such a problem (this is obvious).
As we do use this kind of structure we lack a way of providing this service...
:-D

C'you,

	Massimiliano Pala ([email-masked])
--------------ms6DF0605447C7FE6DE0D98344
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

--------------ms6DF0605447C7FE6DE0D98344--

Sender: [email-masked]
Date: Thu, 03 Feb 2000 10:51:51 +0100
From: Massimiliano Pala <[email-masked]>
Organization: Comune di Modena
To: Antonio Lioy <[email-masked]>
CC: [email-masked]
Subject: Re: More on OCSP and CSL

This is a cryptographically signed message in MIME format.

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

Antonio Lioy wrote:
 
> This is another view: the CSL is being used as a waiting
> list for possibly revoked certs. If it is later revoked,
> then you'll put it in the CRL, otherwise you'll remove it
> from the CSL.
> 
> But I disagree with this view: if I temporarily lost control
> of my smart-card, I can never know what has happened during
> that period of time.

Yes, but I think that if you are not sure about some misusage
of the private key, then you should request it to be revoked.

This is for two reasons: the first is about how long a CSL will
become if we keep track about every suspension of certificates
and the second is about your trusting in your key-pair.

If we keep every suspension tracked on the CSL, it can get a
very long list and it could suffer from problems related to
this aspect (distribution, definition of delta's CSL, and so
on... ). I'd like to avoid these problems as them tend to
get the CSL more complex than needed.

The second aspect is related on the fact that if you do not
trust your key for a certain period, than you should not trust
it at all because it could be open to every kind of attacks:
let's say someone discovers your password and uses it non only
when it is suspended, but he/her can get in touch with your key
during the working time when you are having a coffe-break...

If you are now trusting your key it is possible you think that
the 5 mins of a coffe break do not represent a real danger...

So my vision is: if you trust your certificate is because it has
never been in danger, if there is a possibility your certificate
(read key-pair) has been compromised (so it con be compromised
again...) either if you are not sure about it, than you should
revoke it...

So if we do not keep track on the CSLs about the suspension of
non-revoked certificates is because them are to be trusted.

> May be two years later someone claims money from me, based
> on a digital signature produced during that exact period of
> time. If you removed the entry from the CSL, you'll not be
> able to prove that it was not you that signed that document.
> 
> Do you agree?

I do understand your point of view, but how to solve problems
related to the CSL's length ?? And, moreover, how to be sure
your certificate is subject to attacks only in suspension times ??
Once a key/pair has been compromised (or possibily compromised)
it should not, to me, being trusted any more.

What do you think about this ???

C'you,

	Massimiliano Pala ([email-masked])
--------------msE5E97FA70E2BA6AA670A64F7
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

--------------msE5E97FA70E2BA6AA670A64F7--

From: Simon Tardell <[email-masked]>
To: "'Antonio Lioy'" <[email-masked]>, Juan Rodriguez-Torrent <[email-masked]>
Cc: [email-masked], Russ Housley <[email-masked]>
Subject: RE: OCSP and CSL
Date: Wed, 2 Feb 2000 19:07:56 +0100 

I do tend to agree to some of what Antonio is saying here:

There is a need for a historical account of the status of certificates. The
simplest way of doing this would be to allow multiple CRL entries for a
single certificate in a CRL (e.g. onHold, removeFromCrl, onHold,
keyCompromise) and indicating this extended type of CRL by some extension
(so that the consumer of the CRL understands this special use). This has to
be accompanied by an OCSP request extension that asks the responder to
evaluate the query at some certain historical point in time.

If a CA wants to do allow suspension and unsuspension is purely a policy
issue. If he does, he likely wants to keep track of this status and be able
to communicate this between relying parties in some standard way.

> 1. "revoked" means revoked, i.e. the cert is no more valid
> for any use starting from a certain date

As other people have pointed out 'onHold' (suspension) is really a type of
revocation. Whether this makes sense semantically may be a cultural thing.
For instance, in Swedish the word for revocation ("spärr") indicates that
the certificate is 'barred against use' -- which is true both for a
temporary and permanent revocation. Anyway, I don't think we can change the
words anymore (sorry).

Simon.

Simon Tardell		voice +46 8 7755225, fax +46 8 191499
iD2 Technologies		[email-masked], [email-masked]
Grand Winner of the European IT-prize 1998 http://www.it-prize.org/ 

Date: Wed, 02 Feb 2000 15:36:26 +0100
To: Ilan Shacham <[email-masked]>
From: Mirko Tedaldi <[email-masked]>
Subject: RE: OCSP and CSL
Cc: [email-masked]

At 14.30 02/02/00 +0200, Ilan Shacham wrote:

>Section 3.3 of RFC 2459 clearly states:
>         An entry may be removed from
>    the CRL after appearing on one regularly scheduled CRL issued beyond
>    the revoked certificate's validity period.
>
>If you want to validate an "old" signature, all you have to do is
>retrive the crl that was in order at the time of the signature, to
>see if the certificate was valid at the time.

About it, do you know how commercial PKI softwares work? Do they remove 
expired certificates from CRL ?

Mirko Tedaldi.

Date: Wed, 02 Feb 2000 13:39:41 +0100
From: Joerg Seidel <[email-masked]>
Organization: MAZ Hamburg GmbH
To: Mirko Tedaldi <[email-masked]>, [email-masked]
Subject: Re: OCSP and CSL

Mirko Tedaldi schrieb:

> At 06.26 02/02/00 -0500, Irene Gassko wrote:
>
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> >
> >This is not true. Expired certificates are deleted from CRL.
>
> If I delete expired certificates from CRLs, I could have troubles to verify
> "historical" signatures. Actually, how can I know if a digital signature
> corresponds to a certificate that was valid at the moment of signing and
> now is expired or it corresponds to a revoked certificate?
> I think this matter can happen when you verify old signatures.
>
> Is it right?

Yes, it's a problem. Even if there is a timeAttribute inside of the signature,
you can not trust this time anymore in case of an expired or revoked
certificate. You have to apply a time stamp to the signature after its
generation in order to preserve it's validity after the certificate expiration.
This is the only way to prove that the signature was made prior
revokation/expiration. Btw: This applies to the CRL-signature too.

timeproof has developed a secure hardware based Time Signature System for this
purpose. You are welcome to have a look to our web pages or visit us at CeBIT.

Best regards,
Jörg Seidel
--
timeproof Development                   phone  +49-40-76629-1911
Harburger Schloßstraße 6-12             fax    +49-40-76629-551
D-21079 Hamburg                         mailto:[email-masked]
Germany                                 http://www.timeproof.de

      + + + timeproof CeBIT 2000 Hall 23 Stand A22/14 + + +

From: Ilan Shacham <[email-masked]>
To: "'Antonio Lioy'" <[email-masked]>
Cc: [email-masked]
Subject: RE: OCSP and CSL
Date: Wed, 2 Feb 2000 14:30:20 +0200 

Antonio,

> Irene Gassko wrote:
> > 
> > At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
> > >2. once a cert is inserted into a CRL, it can *never* be
> > >deleted from it
> > 
> > This is not true. Expired certificates are deleted from CRL.
> 
> I disagree. A revoked cert MUST remain in the CRL even after
> its expiration date, because I may be willing to check if
> the cert was valid at some point in time before its natural
> expiration. That's why in a previous mail I said that that
> the size of a CRL is "monotonically increasing": you only
> add revoked certs to the CRL, and NEVER delete them, not
> even after their expiration.
> That's one of the major differences between CRL and OCSP:
> CRL are the history of all revoked certs by a certain CA,
> while OCSP offers information only for the "current" time
> slot (unless the OCSP server supports extensions to also
> look back at the history of the certs).

Section 3.3 of RFC 2459 clearly states:
	An entry may be removed from
   the CRL after appearing on one regularly scheduled CRL issued beyond
   the revoked certificate's validity period.

If you want to validate an "old" signature, all you have to do is
retrive the crl that was in order at the time of the signature, to 
see if the certificate was valid at the time.

Ilan
------------------------------------------------------------------------
Ilan Shacham				mailto:[email-masked]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864

Date: Wed, 02 Feb 2000 12:58:01 +0100
To: [email-masked]
From: Mirko Tedaldi <[email-masked]>
Subject: Re: OCSP and CSL

At 06.26 02/02/00 -0500, Irene Gassko wrote:

> >2. once a cert is inserted into a CRL, it can *never* be
> >deleted from it
>
>This is not true. Expired certificates are deleted from CRL.

If I delete expired certificates from CRLs, I could have troubles to verify 
"historical" signatures. Actually, how can I know if a digital signature 
corresponds to a certificate that was valid at the moment of signing and 
now is expired or it corresponds to a revoked certificate?
I think this matter can happen when you verify old signatures.

Is it right?

Mirko Tedaldi.

Date: Wed, 02 Feb 2000 12:51:06 +0100
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: Irene Gassko <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP and CSL

This is a cryptographically signed message in MIME format.

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

Irene Gassko wrote:
> 
> At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
> >2. once a cert is inserted into a CRL, it can *never* be
> >deleted from it
> 
> This is not true. Expired certificates are deleted from CRL.

I disagree. A revoked cert MUST remain in the CRL even after
its expiration date, because I may be willing to check if
the cert was valid at some point in time before its natural
expiration. That's why in a previous mail I said that that
the size of a CRL is "monotonically increasing": you only
add revoked certs to the CRL, and NEVER delete them, not
even after their expiration.
That's one of the major differences between CRL and OCSP:
CRL are the history of all revoked certs by a certain CA,
while OCSP offers information only for the "current" time
slot (unless the OCSP server supports extensions to also
look back at the history of the certs).

> >Given these considerations, I'm here advocating the
> >technical need for some kind of "cert history". For example,
> >we could extend CRLs (to become a CRSL) to allow each entry
> >to represent a certificate that has been revoked or
> >suspended at least once (so, no need to insert good
> >certificates that expire for natural reasons) and to append
> >a list of suspension periods.
> >For example:
> >   CERT #123
> >   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
> >09:00 GMT+1
> >   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
> >09:00 GMT+1
> >   revoked on 02-feb-2000 09:02 GMT+1
> >That would allow anybody to locally store data and be able
> >to always verify (even offline or in the future) the
> >validity of the certs issued by a certain CA.
>
> This could be useful for archiving purposes.

That's exactly one of my points.

Cheers,

Antonio Lioy
--------------msAC5CC2543B9092E3A473D4DD
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

--------------msAC5CC2543B9092E3A473D4DD--

Date: Wed, 02 Feb 2000 06:26:57 -0500
To: Antonio Lioy <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: OCSP and CSL
Cc: [email-masked]

At 09:46 AM 02/02/2000 +0100, Antonio Lioy wrote:
>Juan Rodriguez-Torrent wrote:
>[snip]
>I'm mildly unsatisfied of the recent discussion over this
>list. It appears that everybody is against certificate
>suspension, given its associated cost. I think that, when
>speaking technically, we should abide from the associated
>costs of operation, because those costs are quite sensitive
>to the perceived needs from the users (otherwise we would
>never define or adopt strong security measures because they
>are surely too expensive :-)
>Moreover, some mails suggest to use CRL with the OnHold
>reason for suspension, and later remove the certificate if
>it is not actually revoked. What??? I have some really bad
>feeling about this solution because my understanding is:
>1. "revoked" means revoked, i.e. the cert is no more valid
>for any use starting from a certain date

If we look for a real world analogy here, I would expect that it
would be instructive to see how credit card companies handle it.
Most will close your account forever, but when I called AMEX
and asked them to close my account, they told me that within
a year I could reopen it if I changed my mind. Hence this is at
least debatable.

>2. once a cert is inserted into a CRL, it can *never* be
>deleted from it 

This is not true. Expired certificates are deleted from CRL.

[snip]
>
>Given these considerations, I'm here advocating the
>technical need for some kind of "cert history". For example,
>we could extend CRLs (to become a CRSL) to allow each entry
>to represent a certificate that has been revoked or
>suspended at least once (so, no need to insert good
>certificates that expire for natural reasons) and to append
>a list of suspension periods.
>For example:
>   CERT #123
>   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
>09:00 GMT+1
>   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
>09:00 GMT+1
>   revoked on 02-feb-2000 09:02 GMT+1
>That would allow anybody to locally store data and be able
>to always verify (even offline or in the future) the
>validity of the certs issued by a certain CA.
>
This could be useful for archiving purposes.

Irene

>Thanks for your attention.
>
>Antonio Lioy
I
----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240

Date: Wed, 02 Feb 2000 12:45:36 +0200
From: Camillo =?iso-8859-1?Q?S=E4rs?= <[email-masked]>
Organization: F-Secure Corporation (formerly Data Fellows Corporation)
To: Antonio Lioy <[email-masked]>
CC: Juan Rodriguez-Torrent <[email-masked]>, [email-masked], Russ Housley <[email-masked]>
Subject: Re: OCSP and CSL

Antonio Lioy wrote:
> One of them asked us for suspending the cert validity associated to a 
> signing engine that cannot be easily removed from the host, because that
> engine should operate only during the physical presence of
> the person legally in charge of the signature.

In that case you are confusing authentication and authorization.  I suggest
considering authorization certificates for this.  They can be very
short-lived and are easy to revoke.  Of course, they are also at least
somewhat controversial at this point.

Suspending the binding between a name and a key is unintuitive, and really
doesn't make sense.  I think you are trying to impose unwanted semantics on
identity certificates!

Regards,
Camillo Särs
-- 
Camillo Särs <[email-masked]>       http://www.iki.fi/ged/
Researcher, Crypto Research                    http://www.F-Secure.com/
F-Secure Corporation   (formerly Data Fellows Corporation)
   F-Secure products: Integrated Solutions for Enterprise Security

Date: Wed, 02 Feb 2000 09:46:27 +0100
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: Juan Rodriguez-Torrent <[email-masked]>
CC: [email-masked], Russ Housley <[email-masked]>
Subject: Re: OCSP and CSL

This is a cryptographically signed message in MIME format.

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

Juan Rodriguez-Torrent wrote:
> 
> Russ, I cannot agree more. I'm just trying to figure out if these are real
> customer requirements or some folks in a glass house tinkering with
> possibilities.

Sorry but I'm quite serious. Although I'm a university
professor, I'm also a practical engineer and I'm not sitting
in a glass house tinkering with possibilities. We are
actively developing a PKI here in Italy and we have
requirements from partners. One of them asked us for
suspending the cert validity associated to a signing engine
that cannot be easily removed from the host, because that
engine should operate only during the physical presence of
the person legally in charge of the signature.
I know that the easiest solution would be to switch off the
machine (and to physically secure it so that nobody can
switch it on) but that cannot be done because the machine
offers other services too. In turn, you could suggest to
duplicate the machine. But I was wondering if there was
nothing simpler like just suspending the certificate. If it
turns out that suspension is a nightmare, fine: I'll suggest
to duplicate the machine, switch it off, and lock it.
But wait a moment: the italian law requires every legally
binding CA:
- to mantain a "signed list of revoked certificates" (they
do use the world CRL and refer to the ISO standard)
- to mantain a "signed list of suspended certificates" (they
do use the world CSL, but they don't define it)
- to permit inquiries over the net to those lists (they
don'use the world OCSP or CRL/CSL distribution over HTTP or
FTP)
so there are lots of CAs here in Italy that are inventing
their own format for CSL.
I just wanted to investigate if teh it was given enough
thoughts to certificate suspension.

I'm mildly unsatisfied of the recent discussion over this
list. It appears that everybody is against certificate
suspension, given its associated cost. I think that, when
speaking technically, we should abide from the associated
costs of operation, because those costs are quite sensitive
to the perceived needs from the users (otherwise we would
never define or adopt strong security measures because they
are surely too expensive :-)
Moreover, some mails suggest to use CRL with the OnHold
reason for suspension, and later remove the certificate if
it is not actually revoked. What??? I have some really bad
feeling about this solution because my understanding is:
1. "revoked" means revoked, i.e. the cert is no more valid
for any use starting from a certain date
2. once a cert is inserted into a CRL, it can *never* be
deleted from it 
If these principles are not true, then please change the
name of CRL to something else, as it doesn't store revoked
certs but temporarly invalid certs. There is nothing more
bad about a standard than using words in a counterintuitive
way.
I ASK FOR A FINAL AUTHORITATIVE WORD HERE: POINT 1 AND 2 ARE
TRUE OR NOT?

Someone advocates more extended usage of OCSP. Apart from
the same terminology issue (the "revoked" status that may be
returned from OCSP doesn't actually mean revoked, hey we are
all joking! if the secondary code is OnHold, check later and
may be it was actually revoked or not) I dislike this
approach because it applies only to on-line transactions: if
I receive a transaction request, then I check the status of
the requesting cert with OCSP and I store the signed answer
as a proof. But there are organizations that want to be
*autonomously* able to perform checks about cert validity at
a certain point in time. Currently, they periodically
request CRLs from their trusted CAs and store them locally.
So even in the case the CA vanishes, they have their own
proof.

Given these considerations, I'm here advocating the
technical need for some kind of "cert history". For example,
we could extend CRLs (to become a CRSL) to allow each entry
to represent a certificate that has been revoked or
suspended at least once (so, no need to insert good
certificates that expire for natural reasons) and to append
a list of suspension periods.
For example:
   CERT #123
   suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000
09:00 GMT+1
   suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000
09:00 GMT+1
   revoked on 02-feb-2000 09:02 GMT+1
That would allow anybody to locally store data and be able
to always verify (even offline or in the future) the
validity of the certs issued by a certain CA.

Thanks for your attention.

Antonio Lioy
--------------msDFE8DE75D5F1236F89C5299F
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

--------------msDFE8DE75D5F1236F89C5299F--

From: "Nick Pope" <[email-masked]>
To: <[email-masked]>
Subject: Request for Information to European Standard on Policies for Certification Service Providers
Date: Tue, 1 Feb 2000 15:50:46 -0000
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BF6CCC.1AE581C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

ETSI (European Telecommunications Standards Institute), as part a general
initiative on standards for electronic signatures, is working on Policies
for Certification Service Providers (CSPs).

It is requested that organisation with interests in this area provides views
on requirements and any existing documentation that may be revelant.  The
attached document provides further details of the Request for Information
and the scope of this activity.

If your organisation has interests in this area can you consider responding
to this RFI.

Thanks

Nick Pope

------=_NextPart_000_0015_01BF6CCC.1AE581C0
Content-Type: application/msword;
	name="ETSI-RFI-fin-25jan00.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ETSI-RFI-fin-25jan00.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAPwAAAAAAAAAA
EAAAQQAAAAEAAAD+////AAAAAD4AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------=_NextPart_000_0015_01BF6CCC.1AE581C0--

From: Philip Hallam-Baker <[email-masked]>
To: "'Juan Rodriguez-Torrent'" <[email-masked]>, [email-masked], Russ Housley <[email-masked]>
Subject: RE: OCSP and CSL
Date: Tue, 1 Feb 2000 08:55:03 -0800 

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01BF6CAB.57348390
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>Russ, I cannot agree more. I'm just trying to figure out if these are
real
>customer requirements or some folks in a glass house tinkering with
>possibilities.

Juan,

	Now that we have real customers doing real business with PKI it
may 
be time to start improving PKIX by throwing out features that are in 
widespread disuse and pare down the schemas to a manageable size. 

	We can anticipate equal success for our researches into porcine 
aviation.

		Phill

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

------=_NextPart_000_0015_01BF6CAB.57348390--

From: Philip Hallam-Baker <[email-masked]>
To: "'Linn, John'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Date: Tue, 1 Feb 2000 07:31:27 -0800 

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF6C9F.A9A9A350
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This attack can be corrected by using the 'exposed MAC' I proposed
in the HTTP security working group in '93 (yahh boo sucks to patent
squaters).

Essentially what one does is to use a MAC to digest the document (I
referred to it as a keyed digest in the prior art). Then one publishes
the key to the MAC along with the digest.

The advantage of this particular scheme is that you can use it to 
harden a system against even exhaustive search (brute force) attacks
with a little ingenuity.

		Phill

-----Original Message-----
From: Linn, John [mailto:[email-masked]]
Sent: Monday, January 31, 2000 4:05 PM
To: [email-masked]'
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

I've a few comments on this specification.

If different entities obtain timestamps on the same data object using
the
same hash algorithm, or a single entity obtains multiple timestamps on
the
same object, the generated timestamp tokens will include identical
message
imprints; as a result, an observer could determine that the timestamps
refer
to the same underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential exposure
is a
concern, some unique value could be generated by the requester and
combined
with a data object before hashing the combination in order to produce
MessageImprint's hashedMessage. 

The second paragraph of Sec. 2.2 bears a number of SHALLs for
verification
steps which are to be performed by the requesting entity once the
TimeStampToken is received.  What's the recommended or required action
if
any of these verifications fail? 

In the Accuracy structure, is no more than one of the seconds, millis,
or
micros OPTIONALs to occur, or may more than one of these elements occur
in
combination? 

In References, [ESS] is now RFC-2634.

Editorially, there's an odd character which seems to recur instead of
the
apostrophe in the phrase "TSA's", and in other places where an
apostrophe or
closing single quote is intended; on my display, it appears as a
ligature
"AE".

Other, minor editorial points:

p. 8, 1st line, "may to be used" -> "may be used".

Later on p. 8, "subtracting the accuracy to" -> "subtracting the
accuracy
from". 

Appendix A, 4th line, "allows to know" -> "allows a verifier to know".

--jl

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

------=_NextPart_000_0005_01BF6C9F.A9A9A350--

Date: Tue, 01 Feb 2000 09:36:26 -0500
From: Christopher Owens <[email-masked]>
Reply-To: [email-masked]
Organization: BBN Technologies, a part of GTE Corporation
To: [email-masked]
Subject: Unsubscribe [email-masked]

Unsubscribe

Unsubscribe [email-masked]