Subject: Re: Questions on Authority/Subject Key Identifiers

From: [email-masked] (Peter Gutmann)
Date: Tue, 24 Sep 2002 18:44:35 +1200 (NZST)

"Tom Gindin" <[email-masked]> writes:

>You should not IMO accept any certificate as a candidate to be the issuer of a
>given certificate unless its subject matches the issuer field.

What if the cert has been reparented, e.g. due to a company reorg or merger?
This is a real-world issue, MS allow chaining by sKID (even if the DNs don't
match) for this reason.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 29 Sep 2002 17:52:22 +1200 (NZST)

Stephen Kent <[email-masked]> writes:

>The real world issue you describe calls for re-issuance of certs; it does not
>justify violating the standards.

In *theory* it calls for the re-issuance of certs.  I can quite easily see
that the practical approach would be to chain by sKID, and obviously enough
people agree with this that they persuaded MS to change the behaviour of their
code to allow it (the issue you're referring to was a bug, not a deliberate
design decision like sKID chaining).

Peter.

---

From: "Tom Gindin" <[email-masked]>
Date: Sun, 29 Sep 2002 10:21:59 -0400

Peter:

      GIven the arbitrary nature of KID's, why is SKID/AKID chaining in the
absence of DN matches even a sensible thing to do?  If everybody used
method 1 in RFC 3280 section 4.2.1.2 (or maybe even method 2, since 2**60
is far beyond the square of the number of CA's in the world), it would be.
However, the comment about "unique values" doesn't seem to have enough
teeth to avoid collisions, and the "monotonically increasing sequence of
integers" technique which is explicitly considered reasonable by RFC's 2459
and 3280 makes collisions between different issuers fairly likely.  X.509
just says they have to be unique in an issuer's space.

            Tom Gindin

[email-masked] (Peter Gutmann)@mail.imc.org on 09/29/2002
01:52:22 AM

Sent by:    [email-masked]

To:    [email-masked], [email-masked]
cc:    [email-masked]
Subject:    Re: Questions on Authority/Subject Key Identifiers

people agree with this that they persuaded MS to change the behaviour of
their

Peter.

Importance: Normal
Sensitivity: 
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Sun, 29 Sep 2002 10:21:59 -0400
Sender: [email-masked]

      Peter:

      GIven the arbitrary nature of KID's, why is SKID/AKID chaining in the
absence of DN matches even a sensible thing to do?  If everybody used
method 1 in RFC 3280 section 4.2.1.2 (or maybe even method 2, since 2**60
is far beyond the square of the number of CA's in the world), it would be.
However, the comment about "unique values" doesn't seem to have enough
teeth to avoid collisions, and the "monotonically increasing sequence of
integers" technique which is explicitly considered reasonable by RFC's 2459
and 3280 makes collisions between different issuers fairly likely.  X.509
just says they have to be unique in an issuer's space.

            Tom Gindin

[email-masked] (Peter Gutmann)@mail.imc.org on 09/29/2002
01:52:22 AM

Sent by:    [email-masked]

To:    [email-masked], [email-masked]
cc:    [email-masked]
Subject:    Re: Questions on Authority/Subject Key Identifiers

people agree with this that they persuaded MS to change the behaviour of
their

Peter.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Date: Sun, 29 Sep 2002 10:20:02 +0200
Sender: [email-masked]

This is indeed an interesting topic...

Essentially there are two ways to make certificates more adapted
to their working environment:

1. Clobber certificates with more "stuff" to as the draft suggests

2. Use a mapping facility that maps a certificate into whatever
    is needed by the working environment

A major advantage with mapping is that you can use TTP-issued
certificates (a.k.a. 100% outsourced PKI), and that the very same
certificates can be used by multiple relying parties in many different
environments.

A major disadvantage with mapping is that Microsoft and probably
most others as well, do not yet support this fundamental capability
except to a very limited extent.  Contributing to that, is the fact that
current PKI-standards do not offer the kind of manageble mapping
support needed for efficient usage of TTP-issued certificates.

If Microsoft and others are to upgrade their PKI support
(which both solutions require), I really hope that they settle
for a mapping solution.

cheers,
Anders

========================================================
    Entities, here denoting individuals and organizations, using the Internet
    for handling sensitive information or performing critical transactions,
    need simple, low-cost, universal, unambiguous, non-forgeable, securely
    multipliable, revocable and renewable "digital handles" to themselves, 
    preferable issued by globally recognized, trusted third parties
========================================================

Date: Sun, 29 Sep 2002 17:52:22 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [email-masked]
Sender: [email-masked]

Peter.

Date: Sat, 28 Sep 2002 15:07:16 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: [email-masked]
Sender: [email-masked]

At 3:53 PM +1200 9/17/02, Peter Gutmann wrote:
>Phil Griffin <[email-masked]> writes:
>
>>Hoping to foment a groundswell of activity, I agree with Russ on this.
>
>Hoping to foment a nice stress-relieving flamewar, I'll agree with Phil that
>since PKIX will standardise anything with an ASN.1 syntax, we may as well do
>this one as well.
>
>Peter >:-).

Fortunately, the comment was so ludicrous that nobody took your 
comment seriously.

Steve

Date: Sat, 28 Sep 2002 15:07:17 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [email-masked]
Sender: [email-masked]

>This is a real-world issue, MS allow chaining by sKID (even if the DNs don't

And MS implementations are non-compliant for this and several other 
reasons that have garnered considerable press recently. The real 
world issue you describe calls for re-issuance of certs; it does not 
justify violating the standards.

Steve

Date: Tue, 24 Sep 2002 18:44:35 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [email-masked]
Sender: [email-masked]

Peter.

From: "Hamrick, Matt" <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
Date: Fri, 27 Sep 2002 17:10:09 -0400
Sender: [email-masked]

Actually.... Joel White over at Tufts (http://www.neurosci.tufts.edu/White/)
is doing some interesting work in this field. I believe he's getting
research dollars to classify and encode scent information for automated
bomb-sniffing devices. I'll probably be chatting with him sometime over the
next couple of weeks, I'll ask him if he wants to write a draft standard for
scent encoding...

/etc
Matt H.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: Friday, September 27, 2002 2:38 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)

I remember the same arguments taking place when we were putting
multimedia into the Web.

People saw the need for inline images - popping up XV windows 
was not very convenient. But Inline movies and sound were generally
considered excessive (at the time the whole of CERN hung off a T1
and that was upmarket connectivity).

And yes people did try to raise scent in the attempt to make
a joke of a serious issue. 

However the arguments against smells are pretty compelling. First
despite trying nobody has developed an effective technology for 
recording or playback.

Second, polyester is a pretty awfull movie and even odourama 
does not save it.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 27, 2002 2:41 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
> 
> 
> 
> Franke Markus <[email-masked]> writes:
> 
> >To fix those security issues we would suggest to add an 
> additional third
> >party harm assertion statement (TPHAS). This TPHAS should be 
> protected by
> >cryptographic means to assure its authenticity and assure that the
> >accompanying scent logotype will not impose undesired 
> physical effects to its
> >receiver.
> 
> The addition of a reliance limit for damage caused by 
> logotype certificate
> extensions would be useful.  This would also cover 
> malicious-MPEG-induced
> epileptic seizures, MP3s with tones at the cranial resonant 
> frequency of your
> pets or designed to shatter the glass in your monitor, and 
> other occurrences.
> 
> Peter.
> 

Reply-To: <[email-masked]>
From: "Peter Hesse" <[email-masked]>
To: =?iso-8859-1?Q?Karol_G=F3rski?= <[email-masked]>, "Terry Hayes" <[email-masked]>, <[email-masked]>, "Russ" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, <[email-masked]>
Subject: RE: Questions on Authority/Subject Key Identifiers
Date: Fri, 27 Sep 2002 15:18:51 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C26639.2F619AD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Karol,

I am not sure that I agree with your interpretation.  It is not clear to me
that AKID/SKID must match for a path to be considered valid.  In fact, I
think that it would be best for path development operations to be written
flexible enough to deal with cases in which AKID/SKID do not match, no
matter which form of AKID is being used.

Here's where I'm coming from: most CA products currently available do not
allow the specification of the subject key identifier of a CA that they are
to cross-certify with.  For example, if A is to cross-certify B, A must
ensure that the certificate A issues to B contains a subject key identifier
that matches the authority key identifier in all certificates B issues.

Currently, when most CA products perform cross-certification, they calculate
the SKID based upon the public key.  Hopefully, if the CAs are the same
brand, or due to luck or configuration, they will calculate the SKID in the
same fashion.  However, since there are no guarantees on how the SKID is
calculated (the methods provided in RFC 2459/3280 are just common methods,
not requirements) it is quite possible that this will result in a mismatch.

If your path development algorithm cannot handle this mismatch, you will be
unable to build a path when a valid one exists.  Certainly matching
AKID/SKID should take priority over those that do not, but last I checked
there is nothing in the certificate path validation process for X.509, RFC
2459, or RFC 3280 that fails a path based upon a mismatched AKID/SKID.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Karol G�rski
  Sent: Tuesday, September 24, 2002 4:33 AM
  To: Terry Hayes; [email-masked]; Russ
  Cc: Tom Gindin; [email-masked]
  Subject: Re: Questions on Authority/Subject Key Identifiers

  Quoting from X.509:2000 (section 8.2.2.1 Authority key identifier
extension):

  "The key may be identified by an explicit key identifier in the
keyIdentifier component, by identification of a certificate for the key
(giving certificate issuer in the authorityCertIssuer component and
certificate serial number in the authorityCertSerialNumber component) or by
both explicit key identifier and identification of a certificate for the
key. If both forms of identification are used then the certificate or CRL
issuer shall ensure they are consistent."

  and:

  "The keyIdentifier form can be used to select CA certificates during path
construction. The authorityCertIssuer, authorityCertSerialNumber pair can
only be used to provide preference to one certificate over others during
path construction."

  I interpret the last sentence in the following way: during path
construction I can look for certificates which match the identifier in the
keyIdentifier component. If among them I find a certificate which matches
the given issuer/serial number pair I treat it as the preferred certificate
to use. If not (ie. my certificate search failed to find the certificate
which the CA indicated as the preferred certificate to use) then I can use
any certificate among them and in this case there will be a mismatch between
the issuer/serial number fields in the subject certificate and issuer
certificate. However, the names must still match for validation to be
succesful so I would expect that the only mismatch may be in the serial
number.

  Karol Gorski

  ----- Original Message -----
    From: Terry Hayes
    To: [email-masked] ; Russ
    Cc: Tom Gindin ; [email-masked]
    Sent: Tuesday, September 24, 2002 12:15 AM
    Subject: Re: Questions on Authority/Subject Key Identifiers

    Russ,

    Yes, this is the case that I am talking about. � All validation
algorithms (include the RFC 3280) require the matching that Tom describes. �
The issue I'm raising is the correct handling during path construction
(discovery) when a certificate seems to have contradictory information about
the certificate for the issuer.

    So far I have one response in favor of � continuing to build a path as
long a one of the values in the authority key identifier extension matches
the data in the potential issuer's certificate. (Russ, please correct if I'm
misinterpreting).

    Terry

    Housley, Russ wrote:

      Tom:

      I believe that Terry is asking about the issuer/serial form of
identifying
      the issuer certificate in the authority key identifier extension.�
So,
      within the extension, the issuer field identifies the issuer of the
      issuer's certificate, and the serial identifies the issuer's
certificate.

      Russ

      At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:

      >� � � � � �  Terry:
      >
      >� � � � � �  The interpretation in #2 looks very dangerous.�  You
should not IMO
      >accept any certificate as a candidate to be the issuer of a given
      >certificate unless its subject matches the issuer field.�  Outside
the PKIX
      >profile, you might allow a case with issuer null and issuerAltName
      >non-null, and then match the candidate issuing certificate's
subjectAltName
      >against issuerAltName.�  I don't think that serialNumber even gets
involved
      >in this matching.�  Even the public key, let alone the key id, is a
      >necessary but not sufficient element of a chaining match.
      >� � � � � �  I hope somebody else will comment on #1 and #3, where I
have nothing
      >useful to say.
      >
      >� � � � � � � � � � � �  Tom Gindin
      >
    My original question:

      >2) Assume that both the keyIdentifier and issuer name/serial number
fields
      >of the authority key identifier are present in a certificate.�
Should both
      >values match the issuer's certificate?�  Would it make sense to use a
      >certificate for the issuer that matches keyIdentifier fields, even
though
      >it doesn't match the issuer name/serial number values?
      >
      >

------=_NextPart_000_0006_01C26639.2F619AD0
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>Karol,</FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>I am not sure that I agree with your interpretation.&nbsp; It =
is not=20
clear to me that AKID/SKID must match for a path to be considered =
valid.&nbsp;=20
In fact, I think that it would be best for path development operations =
to be=20
written flexible enough to deal with cases in which AKID/SKID do not =
match, no=20
matter which form of AKID is being used.</FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>Here's where I'm coming from: most CA products currently =
available do not=20
allow the specification of the subject key identifier of a CA that they =
are to=20
cross-certify with.&nbsp; For example, if A is to cross-certify B, A =
must ensure=20
that the certificate A issues to B contains a subject key identifier =
that=20
matches the authority key identifier&nbsp;in all certificates&nbsp;B=20
issues.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>Currently, when most CA products perform cross-certification, =
they=20
calculate the SKID based upon the public key.&nbsp; Hopefully, if the =
CAs are=20
the same brand, or due to luck or configuration, they =
will&nbsp;calculate the=20
SKID in the same fashion.&nbsp; However, s</FONT></SPAN><SPAN=20
class=3D849400319-27092002><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2>ince=20
there are no guarantees on how the SKID is calculated (the methods =
provided in=20
RFC 2459/3280 are just common methods, not requirements) it is quite =
possible=20
that this will result in a mismatch.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D849400319-27092002><FONT face=3D"Comic Sans MS" =
color=3D#800080=20
size=3D2>If your path development algorithm cannot handle this mismatch, =
you will=20
be unable to build a path when a valid one exists.&nbsp; Certainly =
matching=20
AKID/SKID should take priority over those that do not, but last I =
checked there=20
is nothing in the certificate path validation process for X.509, RFC =
2459, or=20
RFC 3280 that fails a path based upon a mismatched=20
AKID/SKID.</FONT></SPAN></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#800080 size=3D2><SPAN=20
class=3D849400319-27092002>--Peter</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#800080 =
size=3D2></FONT>&nbsp;</DIV><FONT=20
face=3D"Courier New" size=3D2><FONT=20
color=3Dgray>+-----------------------------------------------------------=
----+<BR>|&nbsp;</FONT><FONT=20
color=3D#3333cc>Peter=20
Hesse</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT=20
color=3Dblue>[email-masked]</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;<FONT=20
color=3Dgray>|<BR>|&nbsp;</FONT><FONT color=3D#3333cc>Phone:=20
(703)934-2031</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;<FONT=20
color=3D#3333cc>Gemini Security Solutions, Inc.&nbsp;&nbsp;</FONT><FONT=20
color=3Dgray>|<BR>|&nbsp;</FONT><FONT color=3D#3333cc>ICQ:=20
1942828</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT =

color=3Dblue>www.geminisecurity.com</FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;<FONT=20
color=3Dgray>|<BR>+------------------------------------------------------=
---------+<BR><FONT=20
color=3Dteal>"Pay no attention to what the critics say; there has never =
been <BR>a=20
statue set up in honor of a critic." --Jean =
Sibelius</FONT><BR></FONT></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Karol=20
  G=F3rski<BR><B>Sent:</B> Tuesday, September 24, 2002 4:33 =
AM<BR><B>To:</B> Terry=20
  Hayes; [email-masked]; Russ<BR><B>Cc:</B> Tom Gindin;=20
  [email-masked]<BR><B>Subject:</B> Re: Questions on =
Authority/Subject Key=20
  Identifiers<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Quoting from X.509:2000 (section =
8.2.2.1=20
  Authority key identifier extension):</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>"The key may be identified by an =
explicit key=20
  identifier in the keyIdentifier component, by identification of a =
certificate=20
  for the key (giving certificate issuer in the authorityCertIssuer =
component=20
  and certificate serial number in the authorityCertSerialNumber =
component) or=20
  by both explicit key identifier and identification of a certificate =
for the=20
  key. If both forms of identification are used then the certificate or =
CRL=20
  issuer shall ensure they are consistent."</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>and:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>"The keyIdentifier form can be used =
to select CA=20
  certificates during path construction. The authorityCertIssuer,=20
  authorityCertSerialNumber pair can only be used to provide preference =
to one=20
  certificate over others during path construction."</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I interpret the last sentence in the =
following=20
  way: during path construction I can look for certificates which match =
the=20
  identifier in the keyIdentifier component. If among them I find&nbsp;a =

  certificate which matches the given issuer/serial number pair I treat =
it as=20
  the preferred certificate to use. If not (ie. my certificate search =
failed to=20
  find the certificate which the CA indicated as the preferred =
certificate to=20
  use) then I can use any certificate among them and in this case there =
will be=20
  a mismatch between the issuer/serial number fields in the subject =
certificate=20
  and issuer certificate. However, the names must still match for =
validation to=20
  be succesful so I would expect that the only mismatch may be in the =
serial=20
  number.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Karol Gorski</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV>----- Original Message ----- </DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[email-masked] =
href=3D"mailto:[email-masked]">Terry=20
    Hayes</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]">Russ</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">Tom Gindin</A> ; <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 24, =
2002 12:15=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Questions on=20
    Authority/Subject Key Identifiers</DIV>
    <DIV><BR></DIV>Russ,<BR><BR>Yes, this is the case that I am talking =
about.=20
    =C2&nbsp;All validation algorithms (include the RFC 3280) require =
the matching=20
    that Tom describes. =C2&nbsp;The issue I'm raising is the correct =
handling=20
    during path construction (discovery) when a certificate seems to =
have=20
    contradictory information about the certificate for the =
issuer.<BR><BR>So=20
    far I have one response in favor of =C2&nbsp;continuing to build a =
path as=20
    long a one of the values in the authority key identifier extension =
matches=20
    the data in the potential issuer's certificate. (Russ, please =
correct if I'm=20
    misinterpreting).<BR><BR>Terry<BR><BR>Housley, Russ wrote:=20
    <P></P>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue =
thin solid"=20
    type=3D"cite"><TT><BR>Tom: <BR><BR>I believe that Terry is asking =
about the=20
      issuer/serial form of identifying <BR>the issuer certificate in =
the=20
      authority key identifier extension.=C2&nbsp; So, <BR>within the =
extension,=20
      the issuer field identifies the issuer of the <BR>issuer's =
certificate,=20
      and the serial identifies the issuer's certificate. <BR><BR>Russ=20
      <BR><BR>At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:=20
      =
<BR><BR><BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; =
Terry: <BR>&gt;=20
      <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; The =
interpretation in=20
      #2 looks very dangerous.=C2&nbsp; You should not IMO =
<BR>&gt;accept any=20
      certificate as a candidate to be the issuer of a given =
<BR>&gt;certificate=20
      unless its subject matches the issuer field.=C2&nbsp; Outside the =
PKIX=20
      <BR>&gt;profile, you might allow a case with issuer null and =
issuerAltName=20
      <BR>&gt;non-null, and then match the candidate issuing =
certificate's=20
      subjectAltName <BR>&gt;against issuerAltName.=C2&nbsp; I don't =
think that=20
      serialNumber even gets involved <BR>&gt;in this matching.=C2&nbsp; =
Even the=20
      public key, let alone the key id, is a <BR>&gt;necessary but not=20
      sufficient element of a chaining match.=20
      <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; I =
hope somebody else=20
      will comment on #1 and #3, where I have nothing <BR>&gt;useful to =
say.=20
      <BR>&gt;=20
      =
<BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2=
&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=20
      Tom Gindin <BR>&gt; </TT></BLOCKQUOTE>My original question:<BR>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue =
thin solid"=20
    type=3D"cite"><TT><BR>&gt;2) Assume that both the keyIdentifier and =
issuer=20
      name/serial number fields <BR>&gt;of the authority key identifier =
are=20
      present in a certificate.=C2&nbsp; Should both <BR>&gt;values =
match the=20
      issuer's certificate?=C2&nbsp; Would it make sense to use a=20
      <BR>&gt;certificate for the issuer that matches keyIdentifier =
fields, even=20
      though <BR>&gt;it doesn't match the issuer name/serial number =
values?=20
      <BR>&gt; =
<BR>&gt;<BR></TT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0006_01C26639.2F619AD0--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
Date: Fri, 27 Sep 2002 11:38:17 -0700
Sender: [email-masked]

I remember the same arguments taking place when we were putting
multimedia into the Web.

People saw the need for inline images - popping up XV windows 
was not very convenient. But Inline movies and sound were generally
considered excessive (at the time the whole of CERN hung off a T1
and that was upmarket connectivity).

And yes people did try to raise scent in the attempt to make
a joke of a serious issue. 

However the arguments against smells are pretty compelling. First
despite trying nobody has developed an effective technology for 
recording or playback.

Second, polyester is a pretty awfull movie and even odourama 
does not save it.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 27, 2002 2:41 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
> 
> 
> 
> Franke Markus <[email-masked]> writes:
> 
> >To fix those security issues we would suggest to add an 
> additional third
> >party harm assertion statement (TPHAS). This TPHAS should be 
> protected by
> >cryptographic means to assure its authenticity and assure that the
> >accompanying scent logotype will not impose undesired 
> physical effects to its
> >receiver.
> 
> The addition of a reliance limit for damage caused by 
> logotype certificate
> extensions would be useful.  This would also cover 
> malicious-MPEG-induced
> epileptic seizures, MP3s with tones at the cranial resonant 
> frequency of your
> pets or designed to shatter the glass in your monitor, and 
> other occurrences.
> 
> Peter.
> 

Date: Fri, 27 Sep 2002 18:41:20 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt)
Sender: [email-masked]

Franke Markus <[email-masked]> writes:

>To fix those security issues we would suggest to add an additional third
>party harm assertion statement (TPHAS). This TPHAS should be protected by
>cryptographic means to assure its authenticity and assure that the
>accompanying scent logotype will not impose undesired physical effects to its
>receiver.

The addition of a reliance limit for damage caused by logotype certificate
extensions would be useful.  This would also cover malicious-MPEG-induced
epileptic seizures, MP3s with tones at the cranial resonant frequency of your
pets or designed to shatter the glass in your monitor, and other occurrences.

Peter.

From: Franke Markus <[email-masked]>
To: [email-masked]
Subject: RE: Comments on (draft-ietf-pkix-logotypes-05.txt) 
Date: Fri, 27 Sep 2002 08:13:01 +0200
Sender: [email-masked]

Basically we're very positive with your proposal. Unfortunately we 
observed some shortcomings in section 7.1 "Security considerations". 

As opposed to other known PKIX mechanisms, scent logotypes might be abused 
to cause immediate physical harm to the relying party. Especially allergic 
subjects might be affected by scent logotypes from e.g. an online flower 
store. Worst case, scent logotypes might also be abused for terroristic 
attack.

To fix those security issues we would suggest to add an additional third 
party harm assertion statement (TPHAS). This TPHAS should be protected by
cryptographic means to assure its authenticity and assure that the 
accompanying scent logotype will not impose undesired physical effects to 
its receiver.

In case we get some positive feedback we could provide a more extensive 
outline for the intended TPHAS syntax and processing. There is already 
some activity here to define this as a new XML language extension 
(TPHASML).

Regards,

Markus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 26, 2002 4:41 AM
To: [email-masked]
Subject: Re: Comments on (draft-ietf-pkix-logotypes-05.txt) 

First, Bob Jueneman suggested MPEGs in certificates as a joke.  This is now
being standardised in the logotypes draft.

Then I suggested theme music in certificates as a joke.  This is now being
standardised in the logotypes draft.

Now, in an attempt to make the discussion even more surreal, I give you...

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, and the NRA would use a heady mixture
of cordite and gun oil.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

      LogotypeScent ::= SEQUENCE {
         scentSubtype    IA5String, -- MIME scent subtype
         scent           OCTET STRING }

A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.

Date: Fri, 27 Sep 2002 17:14:31 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Scent logotypes minor update
Sender: [email-masked]

I got quite a bit of feedback on this, attached below is a revised version
with improvements suggested by various people (you know who you are :-).

(Incidentally, I do know what irony is: It's like goldy and silvery, only
 cheaper).

-- Snip --

First, Bob Jueneman suggested MPEGs in certificates as a joke.  This is now
being standardised in the logotypes draft.

Then I suggested theme music in certificates as a joke.  This is now being
standardised in the logotypes draft.

Now, in an attempt to make the discussion even more surreal, I give you...

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, the NRA would use a heady mixture of
cordite and gun oil, and PKIX could use cold coffee and stale cigarette smoke.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

      LogotypeScent ::= SEQUENCE {
         scentSubtype     IA5String, -- MIME scent subtype
         scent            OCTET STRING,
         refreshInfo      ScentRefreshInfo OPTIONAL
         }
      
A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

Since scents fade over time, it may be necessary to periodically refresh the
scent to preserve the user experience:

      ScentRefreshInfo ::= SEQUENCE {
         refreshTime      INTEGER DEFAULT 30,
         refreshCount [0] INTEGER DEFAULT 1,
         refreshUrl       IA5String,
         refreshUrlHash   OCTET STRING OPTIONAL }

The refresh time specifies the time in seconds after which the scent must be
refreshed, the refresh count specifies the number of times the scent should be
refreshed after initial deployment, and the URL and optional hash of the data
stored at the URL location contains the scent payload and integrity protection
mechanism.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.

Intensive usage of scent logotypes may trigger smoke alarms and, by extension,
sprinkler systems.  Users should be aware of this and carry an umbrella.

Certificate users involved in skunkworks projects are discouraged from adding
scent logotypes to their certificates.

Date: Thu, 26 Sep 2002 13:11:11 -0400
From: Steve Hanna <[email-masked]>
To: Marc Jadoul <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

Marc Jadoul wrote:
> Sometimes it is better to break things! Having 2 users with
> the same email address except cases is really a stupid thing
> to do, and you won't break that much by changing that! Seems
> more like fixing things to me.
>
> Does it exist 1 real world example for having as requirement
> 'cases sensitive email addresses'?

But Ned Freed (one of the authors of the MIME spec) wrote:
> This requirement is well understood by those of us who work
> on email software. Any package that fails to support it gets
> in trouble sooner or later. Indeed, software that preserves
> case but isn't capable of supporting case sensitivity for
> domains it has administrative control over can be problematic.
> I've seen software sales won or lost over this issue.

So apparently there are real customers who care about this
issue, real software that implements case-sensitive matching
for local-part, and long-standing standards that say SMTP
servers must treat local-part as case-sensitive. I'm sure
this question was considered carefully when RFC 2821 and
RFC 2822 were developed. A decision was made to keep handling
local-part as case-sensitive.

The conclusion seems clear to me. We must change the successor
to RFC 3280 to say that local-part should be matched using
case-sensitive matching.

-Steve

Date: Thu, 26 Sep 2002 09:46:06 -0700
To: Marc Jadoul <[email-masked]>, Steve Hanna <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: RFC 3280 error WRT rfc822Name
Cc: [email-masked]
Sender: [email-masked]

At 12:10 PM 9/25/2002 +0200, Marc Jadoul wrote:

>Sometimes it is better to break things!

I agree that can be true, though you generally need a transition plan.

>Having 2 users with the same email
>address except cases is really a stupid thing to do,

That's probably true in general, but someone some where may have a 
non-stupid use. For example they have layered some application on top of 
email that involved user identification that is case sensitive and that 
application is one that can't be modified. Or maybe some one has a gateway 
to another mail system that is case sensitive.

>  and you won't break
>that much by changing that!

RFC-822 email addresses are used by more than 100 million users and 
thousands of products. These addresses are even used outside of email in 
things like SIP. Today the rules you follow for this particular part of the 
standard are clear.

If we were to change the rules to say that case doesn't matter then we 
should say that all software using these addresses should do comparisons 
independent of case. It would take years for all the currently deployed 
servers and clients to be upgraded to have that behavior. We'd probably 
never really get it straight. It would probably also take a few years to 
update RFC 2822.

>Seems more like fixing things to me.
>Does it exist 1 real world example for having as requirement 'cases
>sensitive email addresses'?

Don't have a really good concrete example (which doesn't mean one doesn't 
exist). What I would offer is the fact that UNIX, Linux, and Solaris login 
names are case sensitive even though sendmail seems to ignore the case.

LL

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-usergroup-01.txt
Date: Thu, 26 Sep 2002 08:34:56 -0400
Sender: [email-masked]

--NextPart

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

	Title		: The PKIX UserGroupName GeneralName Type
	Author(s)	: M. StJohns
	Filename	: draft-ietf-pkix-usergroup-01.txt
	Pages		: 14
	Date		: 2002-9-25
	
A number of systems which understand X.509 client certificates have
developed various ad hoc mechanisms to map a certificate to a
'userid'/'group(s)' value which can then be used for access control.
The mechanisms include idiosyncratic name forms for the SubjectName
field such as encoding the userid as a CommonName and the group as an
OrganizationalUnit, or mapping the certificate against an entry in a
directory system.  This document describes an otherName extension of
the GeneralName type which can be used in the SubjectAltName
extension or IssuerAltName extension to directly encode userid and
group information.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 26 Sep 2002 14:41:10 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Comments on (draft-ietf-pkix-logotypes-05.txt) 
Sender: [email-masked]

First, Bob Jueneman suggested MPEGs in certificates as a joke.  This is now
being standardised in the logotypes draft.

Then I suggested theme music in certificates as a joke.  This is now being
standardised in the logotypes draft.

Now, in an attempt to make the discussion even more surreal, I give you...

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, and the NRA would use a heady mixture
of cordite and gun oil.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

      LogotypeScent ::= SEQUENCE {
         scentSubtype    IA5String, -- MIME scent subtype
         scent           OCTET STRING }

A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.

From: "Marc Jadoul" <[email-masked]>
To: "Steve Hanna" <[email-masked]>, "Laurence Lundblade" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RFC 3280 error WRT rfc822Name
Date: Wed, 25 Sep 2002 12:10:06 +0200
Sender: [email-masked]

Sometimes it is better to break things! Having 2 users with the same email
address except cases is really a stupid thing to do, and you won't break
that much by changing that! Seems more like fixing things to me.
Does it exist 1 real world example for having as requirement 'cases
sensitive email addresses'?

Actually I suppose (Please confirm if you know) that most smime clients will
choose the certificates to encrypt emails using a case insensitive matching
of the destination email addresses. There will be less problems if we change
RFC 282? than if we have to change all the smime clients and if we need to
teach to users to be carefull with cases in the first part of the email
address...

Regards,

Marc Jadoul

----- Original Message -----
From: "Laurence Lundblade" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>; "Steve Hanna"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 24, 2002 10:32 PM
Subject: Re: RFC 3280 error WRT rfc822Name

>
> At 10:41 AM 9/18/2002 +0200, Marc Jadoul wrote:
>
> >Seems a BIG problem to me!
> >
> >May be RFC 3280 is wrong in his understanding of RFC 822.
> >But RFC 822 (or ...) is probably wrong in doing things so complex for End
> >Users.
> >And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
> >
> >Why is it like this in RFC 822 and successor?
>
>
> The original reason was backward compatibility. 822 (actually I think it
> was RFC 733) was designed to be compatible with a number of existing email
> systems (a very long time ago).
>
> The reason it can't change is also backward compatibility. Such a change
> would cause any current conforming mail system that allows case-sensitive
> mailboxes to become non-conforming.
>
> LL
>
>

Date: Tue, 24 Sep 2002 13:32:20 -0700
To: Marc Jadoul <[email-masked]>, Steve Hanna <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: RFC 3280 error WRT rfc822Name
Cc: [email-masked]
Sender: [email-masked]

At 10:41 AM 9/18/2002 +0200, Marc Jadoul wrote:

>Seems a BIG problem to me!
>
>May be RFC 3280 is wrong in his understanding of RFC 822.
>But RFC 822 (or ...) is probably wrong in doing things so complex for End
>Users.
>And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
>
>Why is it like this in RFC 822 and successor?

The original reason was backward compatibility. 822 (actually I think it 
was RFC 733) was designed to be compatible with a number of existing email 
systems (a very long time ago).

The reason it can't change is also backward compatibility. Such a change 
would cause any current conforming mail system that allows case-sensitive 
mailboxes to become non-conforming.

LL

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 24 Sep 2002 09:48:39 -0400
Subject: Re: Questions on Authority/Subject Key Identifiers
Sender: [email-masked]

Terry:

>> >3) Assume that a self-issued certificate (matching subject and issuer
>> >names) contains only a subject key identifier extension (the authority key
>> >identifier is omitted as suggested in the RFC). Is it reasonable to assume
>> >this certificate is self signed, and terminate the construction of the 
>> path?
>>
>>I do not understand this one.  Self-issued certificates can appear in the
>>middle of valid paths.  I expect them to occur during key rollover for an
>>intermediate CA.
>
>Yes, I agree that these certificates may appear in the middle of 
>paths.  I'm looking for a rule to tell when the certificate is actually 
>self-signed, and therefore a "root".
>
>I'm suggesting that roots may omit the authority key identifier extension, 
>or may have one with data that matches the subject key identifier in the 
>same certificate.  Other self-issued certificates would need to contain 
>both key identifier extensions, with different values.

I do not think that self-issued is the appropriate "flag" for a trust 
anchor.  An implementation needs to know all of its trust anchors.  So, 
when self-issued certificates are the way that trust anchors are 
ingratiated, you could search the list of trust anchors when a self-issued 
certificate is encountered.  But, do not stop path construction if the 
self-issued certificate does not represent a trust anchor.

Russ

From: =?ISO-8859-1?Q?Karol_G=F3rski?= <[email-masked]>
To: "Terry Hayes" <[email-masked]>, <[email-masked]>, "Russ" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, <[email-masked]>
Subject: Re: Questions on Authority/Subject Key Identifiers
Date: Tue, 24 Sep 2002 10:33:22 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0063_01C263B5.CE495CE0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Quoting from X.509:2000 (section 8.2.2.1 Authority key identifier =
extension):

"The key may be identified by an explicit key identifier in the =
keyIdentifier component, by identification of a certificate for the key =
(giving certificate issuer in the authorityCertIssuer component and =
certificate serial number in the authorityCertSerialNumber component) or =
by both explicit key identifier and identification of a certificate for =
the key. If both forms of identification are used then the certificate =
or CRL issuer shall ensure they are consistent."

and:

"The keyIdentifier form can be used to select CA certificates during =
path construction. The authorityCertIssuer, authorityCertSerialNumber =
pair can only be used to provide preference to one certificate over =
others during path construction."

I interpret the last sentence in the following way: during path =
construction I can look for certificates which match the identifier in =
the keyIdentifier component. If among them I find a certificate which =
matches the given issuer/serial number pair I treat it as the preferred =
certificate to use. If not (ie. my certificate search failed to find the =
certificate which the CA indicated as the preferred certificate to use) =
then I can use any certificate among them and in this case there will be =
a mismatch between the issuer/serial number fields in the subject =
certificate and issuer certificate. However, the names must still match =
for validation to be succesful so I would expect that the only mismatch =
may be in the serial number.

Karol Gorski

----- Original Message -----=20
  From: Terry Hayes=20
  To: [email-masked] ; Russ=20
  Cc: Tom Gindin ; [email-masked]=20
  Sent: Tuesday, September 24, 2002 12:15 AM
  Subject: Re: Questions on Authority/Subject Key Identifiers

  Russ,

  Yes, this is the case that I am talking about. =C2 All validation =
algorithms (include the RFC 3280) require the matching that Tom =
describes. =C2 The issue I'm raising is the correct handling during path =
construction (discovery) when a certificate seems to have contradictory =
information about the certificate for the issuer.

  So far I have one response in favor of =C2 continuing to build a path =
as long a one of the values in the authority key identifier extension =
matches the data in the potential issuer's certificate. (Russ, please =
correct if I'm misinterpreting).

  Terry

  Housley, Russ wrote:=20

    Tom:=20

    I believe that Terry is asking about the issuer/serial form of =
identifying=20
    the issuer certificate in the authority key identifier extension.=C2 =
 So,=20
    within the extension, the issuer field identifies the issuer of the=20
    issuer's certificate, and the serial identifies the issuer's =
certificate.=20

    Russ=20

    At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:=20

    >=C2 =C2 =C2 =C2 =C2 =C2  Terry:=20
    >=20
    >=C2 =C2 =C2 =C2 =C2 =C2  The interpretation in #2 looks very =
dangerous.=C2  You should not IMO=20
    >accept any certificate as a candidate to be the issuer of a given=20
    >certificate unless its subject matches the issuer field.=C2  =
Outside the PKIX=20
    >profile, you might allow a case with issuer null and issuerAltName=20
    >non-null, and then match the candidate issuing certificate's =
subjectAltName=20
    >against issuerAltName.=C2  I don't think that serialNumber even =
gets involved=20
    >in this matching.=C2  Even the public key, let alone the key id, is =
a=20
    >necessary but not sufficient element of a chaining match.=20
    >=C2 =C2 =C2 =C2 =C2 =C2  I hope somebody else will comment on #1 =
and #3, where I have nothing=20
    >useful to say.=20
    >=20
    >=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2  Tom Gindin=20
    >=20
  My original question:

    >2) Assume that both the keyIdentifier and issuer name/serial number =
fields=20
    >of the authority key identifier are present in a certificate.=C2  =
Should both=20
    >values match the issuer's certificate?=C2  Would it make sense to =
use a=20
    >certificate for the issuer that matches keyIdentifier fields, even =
though=20
    >it doesn't match the issuer name/serial number values?=20
    >=20
    >

------=_NextPart_000_0063_01C263B5.CE495CE0
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Quoting from X.509:2000 (section =
8.2.2.1 Authority=20
key identifier extension):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"The key may be identified by an =
explicit key=20
identifier in the keyIdentifier component, by identification of a =
certificate=20
for the key (giving certificate issuer in the authorityCertIssuer =
component and=20
certificate serial number in the authorityCertSerialNumber component) or =
by both=20
explicit key identifier and identification of a certificate for the key. =
If both=20
forms of identification are used then the certificate or CRL issuer =
shall ensure=20
they are consistent."</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>and:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"The keyIdentifier form can be used to =
select CA=20
certificates during path construction. The authorityCertIssuer,=20
authorityCertSerialNumber pair can only be used to provide preference to =
one=20
certificate over others during path construction."</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I interpret the last sentence in the =
following way:=20
during path construction I can look for certificates which match the =
identifier=20
in the keyIdentifier component. If among them I find&nbsp;a certificate =
which=20
matches the given issuer/serial number pair I treat it as the preferred=20
certificate to use. If not (ie. my certificate search failed to find the =

certificate which the CA indicated as the preferred certificate to use) =
then I=20
can use any certificate among them and in this case there will be a =
mismatch=20
between the issuer/serial number fields in the subject certificate and =
issuer=20
certificate. However, the names must still match for validation to be =
succesful=20
so I would expect that the only mismatch may be in the serial=20
number.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Karol Gorski</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] =
href=3D"mailto:[email-masked]">Terry Hayes</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">Russ</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Tom Gindin</A> ; <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 24, =
2002 12:15=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Questions on=20
  Authority/Subject Key Identifiers</DIV>
  <DIV><BR></DIV>Russ,<BR><BR>Yes, this is the case that I am talking =
about.=20
  =C2&nbsp;All validation algorithms (include the RFC 3280) require the =
matching=20
  that Tom describes. =C2&nbsp;The issue I'm raising is the correct =
handling=20
  during path construction (discovery) when a certificate seems to have=20
  contradictory information about the certificate for the =
issuer.<BR><BR>So far=20
  I have one response in favor of =C2&nbsp;continuing to build a path as =
long a=20
  one of the values in the authority key identifier extension matches =
the data=20
  in the potential issuer's certificate. (Russ, please correct if I'm=20
  misinterpreting).<BR><BR>Terry<BR><BR>Housley, Russ wrote:=20
  <P></P>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
  type=3D"cite"><TT><BR>Tom: <BR><BR>I believe that Terry is asking =
about the=20
    issuer/serial form of identifying <BR>the issuer certificate in the=20
    authority key identifier extension.=C2&nbsp; So, <BR>within the =
extension, the=20
    issuer field identifies the issuer of the <BR>issuer's certificate, =
and the=20
    serial identifies the issuer's certificate. <BR><BR>Russ <BR><BR>At =
03:03 PM=20
    9/23/2002 -0400, Tom Gindin wrote:=20
    =
<BR><BR><BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; =
Terry: <BR>&gt;=20
    <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; The =
interpretation in #2=20
    looks very dangerous.=C2&nbsp; You should not IMO <BR>&gt;accept any =

    certificate as a candidate to be the issuer of a given =
<BR>&gt;certificate=20
    unless its subject matches the issuer field.=C2&nbsp; Outside the =
PKIX=20
    <BR>&gt;profile, you might allow a case with issuer null and =
issuerAltName=20
    <BR>&gt;non-null, and then match the candidate issuing certificate's =

    subjectAltName <BR>&gt;against issuerAltName.=C2&nbsp; I don't think =
that=20
    serialNumber even gets involved <BR>&gt;in this matching.=C2&nbsp; =
Even the=20
    public key, let alone the key id, is a <BR>&gt;necessary but not =
sufficient=20
    element of a chaining match.=20
    <BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp; I =
hope somebody else will=20
    comment on #1 and #3, where I have nothing <BR>&gt;useful to say. =
<BR>&gt;=20
    =
<BR>&gt;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2=
&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=C2&nbsp;=20
    Tom Gindin <BR>&gt; </TT></BLOCKQUOTE>My original question:<BR>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin =
solid"=20
  type=3D"cite"><TT><BR>&gt;2) Assume that both the keyIdentifier and =
issuer=20
    name/serial number fields <BR>&gt;of the authority key identifier =
are=20
    present in a certificate.=C2&nbsp; Should both <BR>&gt;values match =
the=20
    issuer's certificate?=C2&nbsp; Would it make sense to use a=20
    <BR>&gt;certificate for the issuer that matches keyIdentifier =
fields, even=20
    though <BR>&gt;it doesn't match the issuer name/serial number =
values?=20
    <BR>&gt; <BR>&gt;<BR></TT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0063_01C263B5.CE495CE0--

Date: Tue, 24 Sep 2002 18:44:35 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Questions on Authority/Subject Key Identifiers
Cc: [email-masked]
Sender: [email-masked]

Peter.

Date: Mon, 23 Sep 2002 15:22:19 -0700
From: [email-masked] (Terry Hayes)
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [email-masked], Russ <[email-masked]>
cc: [email-masked]
Organization: Netscape Communications Corp.
Sender: [email-masked]

Housley, Russ wrote: 
<p> </p>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"> 
  <tt> <br>
 Terry: <br>
 <br>
 As you said in the introduction to your questions, these questions are  <br>
 really beyond the scope of the PKIX RFCs, but I will share my opinion. <br>
 </tt></blockquote>
Agreed, and thanks for responding.<br>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"><tt><br>
 &gt;3) Assume that a self-issued certificate (matching subject and issuer
 <br>
 &gt;names) contains only a subject key identifier extension (the authority
key  <br>
 &gt;identifier is omitted as suggested in the RFC). Is it reasonable to
assume  <br>
 &gt;this certificate is self signed, and terminate the construction of the
path? <br>
 <br>
 I do not understand this one.  Self-issued certificates can appear in the
 <br>
 middle of valid paths.  I expect them to occur during key rollover for an
 <br>
 intermediate CA. <br>
 </tt></blockquote>
<br>
Yes, I agree that these certificates may appear in the middle of paths.  I'm
looking for a rule to tell when the certificate is actually self-signed,
and therefore a "root".<br>
<br>
I'm suggesting that roots may omit the authority key identifier extension,
or may have one with data that matches the subject key identifier in the
same certificate.  Other self-issued certificates would need to contain both
key identifier extensions, with different values.<br>
<br>
Terry<br>

Date: Mon, 23 Sep 2002 15:15:54 -0700
From: [email-masked] (Terry Hayes)
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [email-masked], Russ <[email-masked]>
cc: Tom Gindin <[email-masked]>, [email-masked]
Organization: Netscape Communications Corp.
Sender: [email-masked]

Russ,<br>
<br>
Yes, this is the case that I am talking about.  All validation algorithms
(include the RFC 3280) require the matching that Tom describes.  The issue
I'm raising is the correct handling during path construction (discovery)
when a certificate seems to have contradictory information about the certificate
for the issuer.<br>
<br>
So far I have one response in favor of  continuing to build a path as long
a one of the values in the authority key identifier extension matches the
data in the potential issuer's certificate. (Russ, please correct if I'm
misinterpreting).<br>
<br>
Terry<br>
<br>
Housley, Russ wrote: 
<p> </p>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"> 
  <tt> <br>
 Tom: <br>
 <br>
 I believe that Terry is asking about the issuer/serial form of identifying
 <br>
 the issuer certificate in the authority key identifier extension.  So,  <br>
 within the extension, the issuer field identifies the issuer of the  <br>
 issuer's certificate, and the serial identifies the issuer's certificate. 
  <br>
 <br>
 Russ <br>
 <br>
 At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote: <br>
 <br>
 <br>
 &gt;       Terry: <br>
 &gt; <br>
 &gt;       The interpretation in #2 looks very dangerous.  You should not
IMO <br>
 &gt;accept any certificate as a candidate to be the issuer of a given <br>
 &gt;certificate unless its subject matches the issuer field.  Outside the
PKIX <br>
 &gt;profile, you might allow a case with issuer null and issuerAltName <br>
 &gt;non-null, and then match the candidate issuing certificate's subjectAltName 
  <br>
 &gt;against issuerAltName.  I don't think that serialNumber even gets involved 
  <br>
 &gt;in this matching.  Even the public key, let alone the key id, is a <br>
 &gt;necessary but not sufficient element of a chaining match. <br>
 &gt;       I hope somebody else will comment on #1 and #3, where I have
nothing <br>
 &gt;useful to say. <br>
 &gt; <br>
 &gt;             Tom Gindin <br>
 &gt; </tt></blockquote>
My original question:<br>
<blockquote type="cite"
 style="border-left: thin solid blue; padding-left: 10px; margin-left: 0pt;"><tt><br>
 &gt;2) Assume that both the keyIdentifier and issuer name/serial number
fields <br>
 &gt;of the authority key identifier are present in a certificate.  Should
both <br>
 &gt;values match the issuer's certificate?  Would it make sense to use a 
  <br>
 &gt;certificate for the issuer that matches keyIdentifier fields, even though 
  <br>
 &gt;it doesn't match the issuer name/serial number values? <br>
 &gt; <br>
 &gt;<br>
 </tt> </blockquote>

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 23 Sep 2002 16:36:05 -0400
Subject: Re: Questions on Authority/Subject Key Identifiers
Sender: [email-masked]

Terry:

As you said in the introduction to your questions, these questions are 
really beyond the scope of the PKIX RFCs, but I will share my opinion.

>I have some questions about the use of the authority key identifier and 
>subject key identifier fields during the construction of certificate 
>paths. The PKIX RFC is clear that these extensions do not have a role 
>during the path validation phase, however there seem to be ambiguities in 
>how they should be used to build the path.  These gray areas may lead to 
>interoperability problems when application software fails to build (or 
>rejects) a certain certificate path.
>
>Let me say that some of these questions assume certificates may not follow 
>the PKIX profile as written.  In particular, these situations assume that 
>key identifier extensions may be missing, where they are required by the 
>profile. These questions apply when software is allowing a broader range 
>of certificates than described by the PKIX profile.
>
>1)  Assume an authority key identifier extension with a populated 
>keyIdentifier is present in a certificate. Should a corresponding subject 
>key identifier field be REQUIRED in the issuer's certificate?  That is, 
>should candidate certificates for the issuer be rejected because the 
>subject key identifier is missing?

No.  These are not needed for the certificate path validation algorithm to 
be successful.

>2) Assume that both the keyIdentifier and issuer name/serial number fields 
>of the authority key identifier are present in a certificate.  Should both 
>values match the issuer's certificate?  Would it make sense to use a 
>certificate for the issuer that matches keyIdentifier fields, even though 
>it doesn't match the issuer name/serial number values?

Yes.  These are not needed for the certificate path validation algorithm to 
be successful.

>3) Assume that a self-issued certificate (matching subject and issuer 
>names) contains only a subject key identifier extension (the authority key 
>identifier is omitted as suggested in the RFC). Is it reasonable to assume 
>this certificate is self signed, and terminate the construction of the path?

I do not understand this one.  Self-issued certificates can appear in the 
middle of valid paths.  I expect them to occur during key rollover for an 
intermediate CA.

Russ

From: "Housley, Russ" <[email-masked]>
To: Tom Gindin <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 23 Sep 2002 16:39:33 -0400
Subject: Re: Questions on Authority/Subject Key Identifiers
Sender: [email-masked]

Tom:

I believe that Terry is asking about the issuer/serial form of identifying 
the issuer certificate in the authority key identifier extension.  So, 
within the extension, the issuer field identifies the issuer of the 
issuer's certificate, and the serial identifies the issuer's certificate.

Russ

At 03:03 PM 9/23/2002 -0400, Tom Gindin wrote:

>       Terry:
>
>       The interpretation in #2 looks very dangerous.  You should not IMO
>accept any certificate as a candidate to be the issuer of a given
>certificate unless its subject matches the issuer field.  Outside the PKIX
>profile, you might allow a case with issuer null and issuerAltName
>non-null, and then match the candidate issuing certificate's subjectAltName
>against issuerAltName.  I don't think that serialNumber even gets involved
>in this matching.  Even the public key, let alone the key id, is a
>necessary but not sufficient element of a chaining match.
>       I hope somebody else will comment on #1 and #3, where I have nothing
>useful to say.
>
>             Tom Gindin
>
>[email-masked] (Terry Hayes)@mail.imc.org on 09/23/2002 12:52:07 AM
>
>Sent by:    [email-masked]
>
>
>To:    [email-masked]
>cc:
>Subject:    Questions on Authority/Subject Key Identifiers
>
>
>I have some questions about the use of the authority key identifier and
>subject key identifier fields during the construction of certificate paths.
>The PKIX RFC is clear that these extensions do not have a role during the
>path validation phase, however there seem to be ambiguities in how they
>should be used to build the path.  These gray areas may lead to
>interoperability problems when application software fails to build (or
>rejects) a certain certificate path.
>
>Let me say that some of these questions assume certificates may not follow
>the PKIX profile as written.  In particular, these situations assume that
>key identifier extensions may be missing, where they are required by the
>profile. These questions apply when software is allowing a broader range of
>certificates than described by the PKIX profile.
>
>1)  Assume an authority key identifier extension with a populated
>keyIdentifier is present in a certificate. Should a corresponding subject
>key identifier field be REQUIRED in the issuer's certificate?  That is,
>should candidate certificates for the issuer be rejected because the
>subject key identifier is missing?
>
>2) Assume that both the keyIdentifier and issuer name/serial number fields
>of the authority key identifier are present in a certificate.  Should both
>values match the issuer's certificate?  Would it make sense to use a
>certificate for the issuer that matches keyIdentifier fields, even though
>it doesn't match the issuer name/serial number values?
>
>3) Assume that a self-issued certificate (matching subject and issuer
>names) contains only a subject key identifier extension (the authority key
>identifier is omitted as suggested in the RFC). Is it reasonable to assume
>this certificate is self signed, and terminate the construction of the
>path?
>
>I would appreciate your thoughts on these situations.
>
>Terry Hayes
>[email-masked]

Importance: Normal
Sensitivity: 
Subject: Re: Questions on Authority/Subject Key Identifiers
To: [email-masked] (Terry Hayes)
Cc: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Mon, 23 Sep 2002 15:03:02 -0400
Sender: [email-masked]

      Terry:

      The interpretation in #2 looks very dangerous.  You should not IMO
accept any certificate as a candidate to be the issuer of a given
certificate unless its subject matches the issuer field.  Outside the PKIX
profile, you might allow a case with issuer null and issuerAltName
non-null, and then match the candidate issuing certificate's subjectAltName
against issuerAltName.  I don't think that serialNumber even gets involved
in this matching.  Even the public key, let alone the key id, is a
necessary but not sufficient element of a chaining match.
      I hope somebody else will comment on #1 and #3, where I have nothing
useful to say.

            Tom Gindin

[email-masked] (Terry Hayes)@mail.imc.org on 09/23/2002 12:52:07 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    Questions on Authority/Subject Key Identifiers

I have some questions about the use of the authority key identifier and
subject key identifier fields during the construction of certificate paths.
The PKIX RFC is clear that these extensions do not have a role during the
path validation phase, however there seem to be ambiguities in how they
should be used to build the path. �These gray areas may lead to
interoperability problems when application software fails to build (or
rejects) a certain certificate path.

Let me say that some of these questions assume certificates may not follow
the PKIX profile as written. �In particular, these situations assume that
key identifier extensions may be missing, where they are required by the
profile. These questions apply when software is allowing a broader range of
certificates than described by the PKIX profile.

1) �Assume an authority key identifier extension with a populated
keyIdentifier is present in a certificate. Should a corresponding subject
key identifier field be REQUIRED in the issuer's certificate? �That is,
should candidate certificates for the issuer be rejected because the
subject key identifier is missing?

2) Assume that both the keyIdentifier and issuer name/serial number fields
of the authority key identifier are present in a certificate. �Should both
values match the issuer's certificate? �Would it make sense to use a
certificate for the issuer that matches keyIdentifier fields, even though
it doesn't match the issuer name/serial number values?

3) Assume that a self-issued certificate (matching subject and issuer
names) contains only a subject key identifier extension (the authority key
identifier is omitted as suggested in the RFC). Is it reasonable to assume
this certificate is self signed, and terminate the construction of the
path?

I would appreciate your thoughts on these situations.

Terry Hayes
[email-masked]

From: "Housley, Russ" <[email-masked]>
To: David Maurus <[email-masked]>
Cc: [email-masked]
Date: Mon, 23 Sep 2002 08:28:35 -0400
Subject: Re: Comments to draft-ietf-pkix-logotypes-05.txt
Sender: [email-masked]

David:

>Two comments to the current draft:

Thanks for reading the draft.

>*** 3rd paragraph on page 7: There's a typo
>"...Compliant application MUST display and play more just one (or none) of 
>the images and one (or none) of the audio sequences at the same time."
>
>Presumably this should be "display and play just one", or perhaps "display 
>and play more than just one" ?

I tried to reword the paragraph.  Let me know if I did not resolve the problem.

    If a logotype is represented by more than one image file, then the
    image files MUST contain variants of the roughly the same image.
    Likewise, if a logotype is represented by more than one audio file,
    then the audio files MUST contain variants of the roughly the same
    audio sequence. Compliant applications MUST display more just one (or
    none) of the images and play just one (or none) of the audio
    sequences at the same time.

>*** 4th paragraph on page 9: Unfortunate use of patent-encumbered formats
>'Implementations that support audio MUST support the MP3 audio format 
>(with a MIME type of "audio/mpeg").'
>
>I would propose to make MP3 optional, and make OGG VORBIS 
>("audio/x-vorbis") a MUST
>
>Proposed wording:
>'Implementations that support audio MUST support the OGG Vorbis format 
>(with a MIME type of "audio/x-vorbis"), and might support the MP3 audio 
>format (with a MIME type of "audio/mpeg")'
>
>The reasoning behind my proposal is that otherwise
>=> Selling any software capable of playing this extension would be subject 
>to mp3 licensing terms, i.e. would require obtaining a license from Thomson.
>=> While currently, Thomson does not charge licensing fees for *freely* 
>distributed player software, this might change in the future. This would 
>make it illegal to use free / Open Source software supporting the logo 
>extension without having a license from Thomson.
>=> Selling hardware (Personal Trusted Devices?) playing logotype-audio 
>would be commercially unattractive
>Ogg Vorbis is considered patent free, offers better quality than mp3 
>according to recent studies, and is available in numerous free 
>implementations and as source code with a BSD style license.

The authors selected MP3 because every media player seems to support it.

Before receiving your note, I had never heard of OGG Vorbis.  I did a 
Google search, and I found lots of information.

What do others think about this proposed change?

Russ

Date: Mon, 23 Sep 2002 08:45:36 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Comments to draft-ietf-pkix-logotypes-05.txt
Sender: [email-masked]

At 6:33 PM +0200 9/22/02, David Maurus wrote:
>*** 4th paragraph on page 9: Unfortunate use of patent-encumbered formats
>'Implementations that support audio MUST support the MP3 audio 
>format (with a MIME type of "audio/mpeg").'
>
>I would propose to make MP3 optional, and make OGG VORBIS 
>("audio/x-vorbis") a MUST

It is really likely that the IESG (or at least IANA) will strenuously 
object to an "x-" mediatype. They should.

>=> Selling any software capable of playing this extension would be 
>subject to mp3 licensing terms, i.e. would require obtaining a 
>license from Thomson.

The fact that we know that there are intellectual property issues 
with the MP3 format doesn't mean that we *don't* know that there are 
intellectual property issues with OGG.

>=> While currently, Thomson does not charge licensing fees for 
>*freely* distributed player software, this might change in the 
>future. This would make it illegal to use free / Open Source 
>software supporting the logo extension without having a license from 
>Thomson.

We have no proof that the same won't happen to OGG.

>=> Selling hardware (Personal Trusted Devices?) playing 
>logotype-audio would be commercially unattractive

<aside>Many people on this mailing list would say that is a good thing</aside>

>Ogg Vorbis is considered patent free, offers better quality than mp3 
>according to recent studies, and is available in numerous free 
>implementations and as source code with a BSD style license.

"considered patent free" is a bad phrase to use in the IETF, 
particularly in the PKIX WG.

The audio format debate has been raging for years in the VPIM working 
group. If you really want to make a change to this, go spend some 
time in their archives and then suggest an acceptable type. In the 
meantime, MP3 is a common format with a wide variety of encoders and 
decoders available, some of them freely.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'David Maurus'" <[email-masked]>, [email-masked]
Subject: RE: Comments to draft-ietf-pkix-logotypes-05.txt
Date: Mon, 23 Sep 2002 07:29:55 -0700
Sender: [email-masked]

> *** 4th paragraph on page 9: Unfortunate use of 
> patent-encumbered formats
> 'Implementations that support audio MUST support the MP3 
> audio format (with a MIME type of "audio/mpeg").'
> 
> I would propose to make MP3 optional, and make OGG VORBIS 
> ("audio/x-vorbis") a MUST
> 
> Proposed wording:
> 'Implementations that support audio MUST support the OGG 
> Vorbis format (with a MIME type of "audio/x-vorbis"), and 
> might support the MP3 audio format (with a MIME type of "audio/mpeg")'

I agree we have to change from MUST under IETF IP policy.

'Might' is not standards speak. 

What is the advantage to requiring support for a particular format? There is
none on the CA side since the CA can opt to only include a particular format
(Wave for example).

On the client side the format may well be set by other considerations, i.e.
if I am going to put a sound in the cert it is proabably because the format
is already supported on the platform, I can't see someone implementing Ogg
on an MP3 player just to play the cert jingles...

		Phill

Date: Sun, 22 Sep 2002 21:52:07 -0700
From: [email-masked] (Terry Hayes)
Subject: Questions on Authority/Subject Key Identifiers
To: [email-masked]
Organization: Netscape Communications Corp.
Sender: [email-masked]

I have some questions about the use of the authority key identifier and sub=
ject
key identifier fields during the construction of certificate paths. The PKI=
X
RFC is clear that these extensions do not have a role during the path valid=
ation
phase, however there seem to be ambiguities in how they should be used to
build the path. =A0These gray areas may lead to interoperability problems w=
hen
application software fails to build (or rejects) a certain certificate path=
.<br>
<br>
Let me say that some of these questions assume certificates may not follow
the PKIX profile as written. =A0In particular, these situations assume that
key identifier extensions may be missing, where they are required by the
profile. These questions apply when software is allowing a broader range
of certificates than described by the PKIX profile.<br>
<br>
1) =A0Assume an authority key identifier extension with a populated keyIden=
tifier
is present in a certificate. Should a corresponding subject key identifier
field be REQUIRED in the issuer's certificate? =A0That is, should candidate
certificates for the issuer be rejected because the subject key identifier
is missing?<br>
<br>
2) Assume that both the keyIdentifier and issuer name/serial number fields
of the authority key identifier are present in a certificate. =A0Should bot=
h
values match the issuer's certificate? =A0Would it make sense to use a cert=
ificate
for the issuer that matches keyIdentifier fields, even though it doesn't
match the issuer name/serial number values?<br>
<br>
3) Assume that a self-issued certificate (matching subject and issuer names=
)
contains only a subject key identifier extension (the authority key identif=
ier
is omitted as suggested in the RFC). Is it reasonable to assume this certif=
icate
is self signed, and terminate the construction of the path?<br>
<br>
I would appreciate your thoughts on these situations.<br>
<br>
Terry Hayes<br>
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">t=
[email-masked]</a><br>
<br>

Content-Class: urn:content-classes:message
Subject: Comments on (draft-ietf-pkix-logotypes-05.txt)
Date: Sun, 22 Sep 2002 12:24:57 -0700
From: "David Cross" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I hate to re-visit this late in the game, but...

I would like to strongly propose the following:

Section 3 - Support for the audio format should be optional for clients.
Again, this is a matter of practical implementation and I would like to
esnure that clients and compliant CA MAY support the audio file
logotype.

Section 4.1 - The indirect addressing scheme should be optional for
clients.  The indirect adressing schema MAY be supported by clients and
compliant CA.  I am afraid that unless pre-caching is performed by
clients, this option will not be practical to implement.

Section 7 - Security considerations.  Clients especially should be
cognizant that the URI of a logotype may point to an unusually large
binary object or contain executable code.  Clients MAY impose
constraints on the size or time to download a particular logotype.

Regards,
 
David B. Cross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 19, 2002 4:47 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-05.txt

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

	Title		: Internet X.509 Public Key Infrastructure:
Logotypes in
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-05.txt
	Pages		: 19
	Date		: 2002-9-18
	
This document specifies a certificate extension for including logotypes
in public key certificates and attribute certificates. Please send
comments on this document to the [email-masked] mailing list.

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

Date: Sun, 22 Sep 2002 18:33:37 +0200
From: David Maurus <[email-masked]>
To: [email-masked]
Subject: Comments to draft-ietf-pkix-logotypes-05.txt
Sender: [email-masked]

Two comments to the current draft:

*** 3rd paragraph on page 7: There's a typo
"...Compliant application MUST display and play more just one (or none) of the images and one (or none) of the audio sequences at the same time."

Presumably this should be "display and play just one", or perhaps "display and play more than just one" ?

*** 4th paragraph on page 9: Unfortunate use of patent-encumbered formats
'Implementations that support audio MUST support the MP3 audio format (with a MIME type of "audio/mpeg").'

I would propose to make MP3 optional, and make OGG VORBIS ("audio/x-vorbis") a MUST

Proposed wording:
'Implementations that support audio MUST support the OGG Vorbis format (with a MIME type of "audio/x-vorbis"), and might support the MP3 audio format (with a MIME type of "audio/mpeg")'

The reasoning behind my proposal is that otherwise
=> Selling any software capable of playing this extension would be subject to mp3 licensing terms, i.e. would require obtaining a license from Thomson.
=> While currently, Thomson does not charge licensing fees for *freely* distributed player software, this might change in the future. This would make it illegal to use free / Open Source software supporting the logo extension without having a license from Thomson.
=> Selling hardware (Personal Trusted Devices?) playing logotype-audio would be commercially unattractive 

Ogg Vorbis is considered patent free, offers better quality than mp3 according to recent studies, and is available in numerous free implementations and as source code with a BSD style license.

Best Regards,
David

To: [email-masked]
Subject: Note that 3 documents are in Last Call
Date: Sat, 21 Sep 2002 10:14:39 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]

Folks,

Just a reminder and a bit of an explanation.  There are now three documents in 
WG Last Call within PKIX:  Wireless LAN extension, Policy Requirements for 
TSAs, and Logotypes.

In the past I have staggered WG Last Call, rather than pound the group with 
multiple documents.  However, it is not clear that this strategy has increased 
the quality or auntity of document reviews. In an effort to clear as many of 
the mature documents as possible from our queue before Atlanta, I am initiating 
Last Call whenever a document is ready.

Note that Last Call can be extended.  I will not close Last Call for a document 
if it is being actively discussed on the list.  However, silence will be 
considered acceptance.

Thanks,

Tim Polk

To: [email-masked]
Subject: WG Last Call: Logotypes
Date: Sat, 21 Sep 2002 10:07:39 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]

This email initiates working group Last Call For "Internet X.509 Public Key 
Infrastructure: Logotypes in X.509 certificates", which is available at 

  http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-05.txt

Working Group Last Call will complete on or after October 5, 2002.  This 
document would be recommended as a standards track document.

To: [email-masked]
Subject: WG Last Call: Policy Requirements for TSAs
Date: Sat, 21 Sep 2002 09:59:20 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]

This email initiates Working Group Last Call for the Internet-Draft "Policy 
Requirements for Time-Stamping Authorities", available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-02.txt.

Last Call will close on or after October 5, 2002.  Assuming successful 
completion of Last Call, this document will be recommended for the 
Informational track.

Note that Working Group Last Call is *optional* for Informational Track 
documents.  However, other topics have dominated the mailing list over the last 
year.  To ensure that the maximum number WG members review this document, we 
have chosen to have a Last Call.

Thanks,

Tim POlk

From: Mike Rowan <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, "'Tony Bartoletti'" <[email-masked]>, Mike Rowan <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, Mike Rowan <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 15:27:23 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C260BA.37675E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Good idea, signing makes sense.

- Michael 

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 3:18 PM
To: Tony Bartoletti; Mike Rowan; 'Ambarish Malpani'; Mike Rowan;
[email-masked]'
Subject: RE: formularze (INFECTED)

Perhaps if we all signed our mail with S/MIME?

	Phill

> -----Original Message-----
> From: Tony Bartoletti [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 3:07 PM
> To: Mike Rowan; 'Ambarish Malpani'; Mike Rowan; [email-masked]'
> Subject: RE: formularze (INFECTED)
> 
> 
> 
> All,
> 
> Our laboratory announced yesterday a change in virus-firewall
> protocol.  Upon detecting an incoming infected email, they 
> will simply 
> "cleanse" the mail, and no longer generate separate automatic 
> notification 
> to the intended recipient, nor generate any reply to the (apparent) 
> sender.  This is due to the Klez virus infestation, which 
> spoofs sender 
> addresses by gleaning them from the address books of infected victims.
> 
> What a world.
> 
> Cheers! ____tony____
> 
> At 02:21 PM 9/20/2002 -0400, Mike Rowan wrote:
> 
> >Thanks for the response Ambarish.  As I am sure you know the
> message was
> >sent as a notification to the list.  And, you have gone the
> extra mile to
> >track this.
> >
> >- Michael
> 
> 

------=_NextPart_000_001E_01C260BA.37675E60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_001E_01C260BA.37675E60--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: Tony Bartoletti <[email-masked]>, Mike Rowan <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, Mike Rowan <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 12:17:50 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C260B8.DA26CCA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Perhaps if we all signed our mail with S/MIME?

	Phill

> -----Original Message-----
> From: Tony Bartoletti [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 3:07 PM
> To: Mike Rowan; 'Ambarish Malpani'; Mike Rowan; [email-masked]'
> Subject: RE: formularze (INFECTED)
> 
> 
> 
> All,
> 
> Our laboratory announced yesterday a change in virus-firewall 
> protocol.  Upon detecting an incoming infected email, they 
> will simply 
> "cleanse" the mail, and no longer generate separate automatic 
> notification 
> to the intended recipient, nor generate any reply to the (apparent) 
> sender.  This is due to the Klez virus infestation, which 
> spoofs sender 
> addresses by gleaning them from the address books of infected victims.
> 
> What a world.
> 
> Cheers! ____tony____
> 
> At 02:21 PM 9/20/2002 -0400, Mike Rowan wrote:
> 
> >Thanks for the response Ambarish.  As I am sure you know the 
> message was
> >sent as a notification to the list.  And, you have gone the 
> extra mile to
> >track this.
> >
> >- Michael
> 
> 

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

------=_NextPart_000_0000_01C260B8.DA26CCA0--

Date: Fri, 20 Sep 2002 12:07:12 -0700
To: Mike Rowan <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, Mike Rowan <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: formularze (INFECTED)
Sender: [email-masked]

All,

Our laboratory announced yesterday a change in virus-firewall 
protocol.  Upon detecting an incoming infected email, they will simply 
"cleanse" the mail, and no longer generate separate automatic notification 
to the intended recipient, nor generate any reply to the (apparent) 
sender.  This is due to the Klez virus infestation, which spoofs sender 
addresses by gleaning them from the address books of infected victims.

What a world.

Cheers! ____tony____

At 02:21 PM 9/20/2002 -0400, Mike Rowan wrote:

>Thanks for the response Ambarish.  As I am sure you know the message was
>sent as a notification to the list.  And, you have gone the extra mile to
>track this.
>
>- Michael

From: Mike Rowan <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, Mike Rowan <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 14:21:04 -0400
Sender: [email-masked]

Thanks for the response Ambarish.  As I am sure you know the message was
sent as a notification to the list.  And, you have gone the extra mile to
track this.

- Michael 

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 2:06 PM
To: Mike Rowan; [email-masked]
Subject: RE: formularze (INFECTED)

Hi Mike,
    The mail was a spam. Came from somewhere in Poland. Wasn't sent by me.
Just claims to be sent by me.

Here is a mail I got from Paul (Hoffman):

-------------Begin included mail - including my message to Paul----

>Do you have easy access to the orginal mail you received. I want to 
>know whether the mail actually originated from ValiCert or somebody is 
>just spoofing the name.

I don't have them, but you can see for yourself that it was relayed through
a system in .pl. It's clearly a worm/virus.

The mail log entry says:

Sep 20 07:04:30 above sendmail[12331]: g8KE4Tk12331:
from=<[email-masked]
>, size=39749, class=0, nrcpts=1, 
>msgid=<[email-masked].
com>, proto=SMTP, daemon=MTA25, relay=robot.unizeto.pl [217.153.69.1]

--Paul Hoffman, Director
--Internet Mail Consortium

----------------End Inclusion-------------------------------

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Mike Rowan
> Sent: Friday, September 20, 2002 9:13 AM
> To: 'ambarish'; [email-masked]'
> Subject: RE: formularze (INFECTED)
>
>
>
> Please protect your system with a virus protection engine, these are 
> readily available today.  Below is the information sent in your post 
> to this list. Thank you.
>
> Sender of the infected attachment:  ambarish
> Subject of the message:  formularze
> One or more attachments were quarantined.
>   Attachment formularze.mpg
> .pif was Quarantined for the following reasons:
>     Virus W32.Yaha.F@mm was found.
>
> Michael J. Rowan
> Director, Product Management
> Enterprise Security Services
> GeoTrust, Inc.
> 781.263.4124 (direct)
> 401.952.1240 (mobile)
>
> [email-masked]
> www.geotrust.com
>
>
> -----Original Message-----
> From: ambarish [mailto:[email-masked]]
> Sent: Sunday, September 01, 2002 12:05 PM
> To: [email-masked]
> Subject: formularze
>

From: "Ambarish Malpani" <[email-masked]>
To: "Mike Rowan" <[email-masked]>, <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 11:05:59 -0700
Importance: Normal
Sender: [email-masked]

Hi Mike,
    The mail was a spam. Came from somewhere in Poland. Wasn't
sent by me. Just claims to be sent by me.

Here is a mail I got from Paul (Hoffman):

-------------Begin included mail - including my message to Paul----

>Do you have easy access to the orginal mail you received. I
>want to know whether the mail actually originated from
>ValiCert or somebody is just spoofing the name.

I don't have them, but you can see for yourself that it was relayed
through a system in .pl. It's clearly a worm/virus.

The mail log entry says:

Sep 20 07:04:30 above sendmail[12331]: g8KE4Tk12331:
from=<[email-masked]
>, size=39749, class=0, nrcpts=1,
>msgid=<[email-masked].
com>, proto=SMTP, daemon=MTA25, relay=robot.unizeto.pl [217.153.69.1]

--Paul Hoffman, Director
--Internet Mail Consortium

----------------End Inclusion-------------------------------

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mike Rowan
> Sent: Friday, September 20, 2002 9:13 AM
> To: 'ambarish'; [email-masked]'
> Subject: RE: formularze (INFECTED)
>
>
>
> Please protect your system with a virus protection engine, these
> are readily
> available today.  Below is the information sent in your post to this list.
> Thank you.
>
> Sender of the infected attachment:  ambarish
> Subject of the message:  formularze
> One or more attachments were quarantined.
>   Attachment formularze.mpg
> .pif was Quarantined for the following reasons:
>     Virus W32.Yaha.F@mm was found.
>
> Michael J. Rowan
> Director, Product Management
> Enterprise Security Services
> GeoTrust, Inc.
> 781.263.4124 (direct)
> 401.952.1240 (mobile)
>
> [email-masked]
> www.geotrust.com
>
>
> -----Original Message-----
> From: ambarish [mailto:[email-masked]]
> Sent: Sunday, September 01, 2002 12:05 PM
> To: [email-masked]
> Subject: formularze
>

From: Mike Rowan <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, "'ambarish'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 13:45:16 -0400
Sender: [email-masked]

If you will notice the reply was addressed no one person in particular,
instead was a reply to all.  The message came from someone having post
access to this list.  No need to point fingers nor brag about our virus
knowledge.  The purpose is to post a general message of concern.  No harm
done.

- Michael 

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 1:32 PM
To: 'Mike Rowan'; 'ambarish'; [email-masked]'
Subject: RE: formularze (INFECTED)

Hang on, before getting onto Ambarish, remember that the latest and greatest
strategy of viruses has been to fake the sender ID so that the infected host
is not known.

In some cases the virus causes the infected host to send messages from A
claiming to be from B and vice versa so that two people with completely
uninfected systems are bombarding each other with complaints about viruses.

Paul's mailer does not forward the original headers, proper.com being one of
his hosts so I can't trace the mail.

Received: from mail.imc.org (robot.unizeto.pl [217.153.69.1])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8KE4Tk12331
	for <[email-masked]>; Fri, 20 Sep 2002 07:04:29 -0700 (PDT)
Message-Id: <[email-masked]>

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Mike Rowan'" <[email-masked]>, "'ambarish'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 10:32:19 -0700
Sender: [email-masked]

Hang on, before getting onto Ambarish, remember that the latest and greatest
strategy of viruses has been to fake the sender ID so that the infected host
is not known.

In some cases the virus causes the infected host to send messages from A
claiming to be from B and vice versa so that two people with completely
uninfected systems are bombarding each other with complaints about viruses.

Paul's mailer does not forward the original headers, proper.com being one of
his hosts so I can't trace the mail.

Received: from mail.imc.org (robot.unizeto.pl [217.153.69.1])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8KE4Tk12331
	for <[email-masked]>; Fri, 20 Sep 2002 07:04:29 -0700 (PDT)
Message-Id: <[email-masked]>

From: Mike Rowan <[email-masked]>
To: "'ambarish'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: formularze (INFECTED)
Date: Fri, 20 Sep 2002 12:12:51 -0400
Sender: [email-masked]

Please protect your system with a virus protection engine, these are readily
available today.  Below is the information sent in your post to this list.
Thank you.

Sender of the infected attachment:  ambarish
Subject of the message:  formularze
One or more attachments were quarantined.
  Attachment formularze.mpg
.pif was Quarantined for the following reasons:
    Virus W32.Yaha.F@mm was found.

Michael J. Rowan
Director, Product Management
Enterprise Security Services
GeoTrust, Inc.
781.263.4124 (direct)
401.952.1240 (mobile)

[email-masked]
www.geotrust.com

-----Original Message-----
From: ambarish [mailto:[email-masked]] 
Sent: Sunday, September 01, 2002 12:05 PM
To: [email-masked]
Subject: formularze

From: ambarish<[email-masked]>
To: [email-masked]
Subject: formularze
Date: Fri,20 Sep 2002 16:04:31 PM
Sender: [email-masked]

--sxcxpcc
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<FONT></FONT>
http://www.eforms.com/content/Eform_Companies.html
http://www.formatta.com
http://www.pureedge.com
http://www.beachtech.com
http://www.conciseforms.com
http://www.itmassoc.com
http://www.webbase.com
http://www.quask.com
http://www.primarysoftware.com
http://www.atforms.com
http://www.am<BR>.<BR>.<BR><BR></BODY></HTML>

--sxcxpcc
Content-Type: application/octet-stream;
	name=formularze.mpg                                                                                                                                                                                                                            .pif
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="formularze.mpg                                                                                                                                                                                                                            .pif"

--sxcxpcc--

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 20 Sep 2002 09:51:08 -0400
Subject: PKCS #1 v2.1 Internet-Draft
Sender: [email-masked]

PKCS #1 v2.1 has been published as an Internet-Draft at
http://www.ietf.org/internet-drafts/draft-jonsson-pkcs1-v2dot1-00.txt.

To: [email-masked]
Subject: PKI - LDAP survey
Date: Thu, 19 Sep 2002 18:13:18 -0400 (EDT)
From: [email-masked]
Sender: [email-masked]

PLEASE SEND YOUR REPLIES DIRECTLY TO ME AND NOT TO THE LIST

Background:  There was a change from LDAPv2 to LDAPv3 which affects how 
certificates and related PKI data structures are stored. LDAPv3 added ";binary" 
as a means of specifying transfer syntax for these objects, which should be 
transferred in BER form. Now, however, the LDAPv3 WG has decided to remove 
support for ;binary (which was optional), from the draft standard (due to 
ambiguities in its specification, and no consensus on how to resolve them) in 
an effort to progress to Draft, avoiding other problems associated with generic 
use of this feature. The plan is to reintroduce ;binary as an extension in the 
future, once the problems that caused it to be removed is resolved. There is 
also a PKIX proposal to define a native transfer syntax for certificate (i.e., 
a transfer syntax where ;binary is not specified). 

To determine the interoperability issues that may result from the range of 
solutions, the LDAPbis folks have requested that we survey PKI product vendors 
to determine how current products use LDAP v2 and v3.

Please respond to the following questions for current and recent (e.g., 
available in 2001 or 2002) PKI products.  Answer separately for "major" 
versions:

1. Product type (CA or client?) and name (please include version number):   

For CAs please answer questions 2 - 4; for clients answer 5 - 8.

2. Is the CA designed to publish certificates using LDAP v2, v3, or both?

3. When the CA uses LDAP v2 to store certificates in the directory, how does 
the CA specify the attribute? [check all that apply]

(a) caCertificate;binary           [   ]
(b) caCertificate                  [   ]
(c) userCertificate;binary         [   ]
(d) userCertificate                [   ]
(e) does not support LDAP v2       [   ]

4. When the CA uses LDAP v3 to store certificates in the directory, how does 
the CA specify the attribute description (transfer syntax)? [check all that 
apply]

(a) caCertificate;binary           [   ]
(b) caCertificate                  [   ]
(c) userCertificate;binary         [   ]
(d) userCertificate                [   ]
(e) does not support LDAP v3       [   ]

5. When the client requests certificates, does it make the request using LDAP 
v2, v3, or can it be configured to use either?

6. When requesting certificates, what does the client request? [check all that 
apply]

(a) all user attributes            [   ] 
(b) userCertificate;binary         [   ]
(c) userCertificate                [   ]
(d) caCertificate;binary           [   ]
(e) caCertificate                  [   ]

7. When receiving certificates, what are the expected attribute types/attribute 
descriptions? [check all that apply]

(a) userCertificate;binary         [   ]
(b) userCertificate                [   ]
(c) caCertificate;binary           [   ]
(d) caCertificate                  [   ]

8. What is the failure behaviour if an unexpected attribute types/attribute 
descriptions are encountered?

Please respond directly to [email-masked].  I will be posting a summary but 
will not disclose any specific responses.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-05.txt
Date: Thu, 19 Sep 2002 07:47:29 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: Logotypes in
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-05.txt
	Pages		: 19
	Date		: 2002-9-18
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [email-masked]
mailing list.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Olle Mulmo" <[email-masked]>
To: "Steve Hanna" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Thu, 19 Sep 2002 10:01:01 +0200
Importance: Normal
Sender: [email-masked]

I'm not particulary active on this list, but for whatever it's worth,
my vote is on #3.

The can of works opened when handing out CA certs to every user is
indeed big. Being a minimalistic and the most "pure" approach, as
I see it, it falls because of reality reasons, as the user may too
easily be able to do too much in unexpected contexts.

(That isn't a reason for PKIX to stop working on it, but it does raise
acceptability concerns when pushing it out for deployment.)

My two cents,

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steve Hanna
Sent: den 17 september 2002 17:55
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX

Denis Pinkas wrote:
> > I would prefer an approach that gave a CA certificate to
> > any user
> 
> This is not RFC 3280 compliant. :-(
> 
> > who might need to create a proxy certificate (with
> > name constraints or other limitations to restrict the
> > user's authority).

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve

From: "Olle Mulmo" <[email-masked]>
To: "Steve Hanna" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Thu, 19 Sep 2002 08:53:14 +0200
Importance: Normal
Sender: [email-masked]

I'm not particulary active on this list, but for whatever it's worth,
my vote is on #3.

The can of works opened when handing out CA certs to every user is
indeed big. Being a minimalistic and the most "pure" approach, as
I see it, it falls because of reality reasons, as the user may too
easily be able to do too much in unexpected contexts.

(That isn't a reason for PKIX to stop working on it, but it does raise
acceptability concerns when pushing it out for deployment.)

My two cents,

/Olle

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steve Hanna
Sent: den 17 september 2002 17:55
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX

Denis Pinkas wrote:
> > I would prefer an approach that gave a CA certificate to
> > any user
> 
> This is not RFC 3280 compliant. :-(
> 
> > who might need to create a proxy certificate (with
> > name constraints or other limitations to restrict the
> > user's authority).

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve

To: IETF-Announce: ;
Subject: RFC 3379 on Delegated Path Validation and Delegated Path Discovery Protocol Requirements
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 18 Sep 2002 17:21:39 -0700
Sender: [email-masked]

--NextPart

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

        RFC 3379

        Title:	    Delegated Path Validation and Delegated Path
                    Discovery Protocol Requirements
        Author(s):  D. Pinkas, R. Housley
        Status:	    Informational
	Date:       September 2002
        Mailbox:    [email-masked], [email-masked]
        Pages:      15
        Characters: 32455
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-pkix-dpv-dpd-req-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3379.txt

This document specifies the requirements for Delegated Path Validation
(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
It also specifies the requirements for DPV and DPD policy management.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3379

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3379.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Thu, 19 Sep 2002 00:36:53 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

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

Peter Gutmann wrote:
> PDU ::= SEQUENCE OF ANY

I don't think this is sufficiently general: what if the PDU is more conveniently
represented as a SET or some other type? It should obviously be

MyProtocol DEFINITIONS AUTOMATIC TAGS ::= BEGIN
  PDU ::= CHOICE {
    aSequence    [42] SEQUENCE OF ANY,
    aSet              SET OF ANY,
    anythingElse      ANY,
    ... -- for future extensions
  } OPTIONAL (CONSTRAINED BY {-- the rest of this memo })
END

;-)

- -- 
David Hopwood <[email-masked]>

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

Date: Wed, 18 Sep 2002 11:17:49 -0700
From: Himanshu Chatterjee <[email-masked]>
Organization: Server Technologies
CC: Steve Hanna <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

May be also an issue for those who depend on ldap 'mail' attribute and by
protocol ldap's data is case insensitive.  Himanshu

Marc Jadoul wrote:

> Seems a BIG problem to me!
>
> May be RFC 3280 is wrong in his understanding of RFC 822.
> But RFC 822 (or ...) is probably wrong in doing things so complex for End
> Users.
> And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.
>
> Why is it like this in RFC 822 and successor?
>
> Marc Jadoul
>
> ----- Original Message -----
> From: "Steve Hanna" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, September 17, 2002 11:23 PM
> Subject: RFC 3280 error WRT rfc822Name
>
> >
> > In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
> >
> >    Note that while upper and lower case letters are allowed in an
> >    RFC 822 addr-spec, no significance is attached to the case.
> >
> > But RFC 822 says:
> >
> >         The only syntactic units which requires preservation of
> >         case information are:
> >
> >                     -  text
> >                     -  qtext
> >                     -  dtext
> >                     -  ctext
> >                     -  quoted-pair
> >                     -  local-part, except "Postmaster"
> >
> >         When matching any other syntactic unit, case is to be ignored.
> >
> > And RFC 2821 (the successor to RFC 821 and the companion
> > to RFC 2822, which obsoletes RFC 822) is more explicit:
> >
> >    The local-part of a mailbox MUST BE treated as case sensitive.
> >
> > I have spoken to a few people about this and the consensus
> > seems to be that RFC 3280 is wrong. When matching email
> > addresses (such as when processing name constraints during
> > certificate path validation), the local-part component of
> > an email address must be treated as case-sensitive.
> >
> > If the members of these lists don't agree with this analysis,
> > please speak up. Otherwise, I expect that this will be fixed
> > in the successor to RFC 3280. Note that I don't think this
> > is an especially big deal. I just thought people would want
> > to know of the problem ASAP.
> >
> > Note also that many email servers don't treat local-part as
> > case-sensitive. But some do. There's no way for a certificate
> > processing system to know whether [email-masked] is
> > actually the same mailbox as [email-masked]. So the
> > certificate processing system must treat them as different.
> > At least, that's the rationale for this rule.
> >
> > Thanks,
> >
> > Steve Hanna
> > Sun Microsystems, Inc.
> >

Date: Thu, 19 Sep 2002 03:28:59 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Phil Griffin <[email-masked]> writes:

>Make sure you encapsulate that ANY inside of an OCTET STRING to make it
>lightweight and simple ;-)

Actually it should be an explicitly-tagged OCTET STRING, maybe:

SEQUENCE {
	[0] EXPLICIT OCTET STRING,
	[1] EXPLICIT OCTET STRING,
	[2] EXPLICIT OCTET STRING,
	[3] EXPLICIT OCTET STRING,
	[4] EXPLICIT OCTET STRING
	...
	}

although I'll have to figure out how to do it without the extension marker
since that's much too modern ASN.1 to appear in a PKI RFC.

This is great, I'll have an RFC done in no time :-).

Peter.

Date: Wed, 18 Sep 2002 17:18:41 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked]
Sender: [email-masked]

I had proposed 'Extensions' in the 'simple protocol',
and also an automatic way of detection of different encodings
starting with '0' is BER/DER, '<' is XER, '(' lispish SPKI, any
alpha an 822 header line style. 
 
'0' means null, nothing, nonsense, '<' is inferior,
'(' you always have something else to add, an any alpha
mean lot's of things to tell. 

Date: Wed, 18 Sep 2002 11:16:29 -0400
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter,

Make sure you encapsulate that ANY inside
of an OCTET STRING to make it lightweight
and simple ;-)

Phil

Peter Gutmann wrote:

> =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:
> 
> 
>>So why use GeneralName at all? 
>>Why use an flexible CHOICE data type and then restrict its use to a single
>>variant?
>>
> 
> I'm waiting for an RFC which starts with a SEQUENCE OF ANY, and the rest of the
> RFC is a long list of things you're constrained from putting in there.  Come to
> think of it, I might do that next April, the Grand Unified PKI RFC:
> 
> Protocol Overview
> 
> This RFC standardises a universal PKI protocol which may be described using the
> following procedure:
> 
> 1. Go to your nearest supermarket and purchase a packet of alphabet soup (if
>    you already have alphabet soup in your larder, you may skip this step).
>    
> 2. Following the instructions on the packet, make sufficient alphabet soup to
>    feed the members of your household.
> 
> 3. Plunge a standards-conformant spoon into the soup and extract a sequence
>    (3...MAX, MAX = 6) letters from the soup.  This is the name of the PKI
>    protocol which this RFC standardises.
> 
> 4. Eat the alphabet soup (after writing down the protocol name).
> 
> Protocol Details
> 
> This protocol consists of a single PDU:
> 
> PDU ::= SEQUENCE OF ANY
> 
> The protocol is thus trivial to implement, and universally applicable, since
> anyone can implement it in whichever way they choose, and no-one can feel their
> idea of how a PKI protocol should work has been unfairly excluded.  This makes
> it equivalent to many other PKI protocols, but without requiring pages and
> pages of tedious specification to distract the reader.
> 
> [etc - I'll leave the rest till late March, because the compile has just
>  finished]
> 
> Peter.
> 
> 

From: "Housley, Russ" <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Date: Wed, 18 Sep 2002 10:30:04 -0400
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Sounds like a perfect protocol for publication on 1 April 2003!

Peter Gutmann wrote:
>I'm waiting for an RFC which starts with a SEQUENCE OF ANY,

Date: Wed, 18 Sep 2002 16:23:36 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter Gutmann wrote:
> 
> I'm waiting for an RFC which starts with a SEQUENCE OF ANY,

Peter, this seems to simple. There should be at least one CHOICE and an 
OPTIONAL key word in there making it look more nested. ;-)

Ciao, Michael.

Date: Thu, 19 Sep 2002 02:18:23 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked]
Sender: [email-masked]

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:

>So why use GeneralName at all? 
>Why use an flexible CHOICE data type and then restrict its use to a single
>variant?

I'm waiting for an RFC which starts with a SEQUENCE OF ANY, and the rest of the
RFC is a long list of things you're constrained from putting in there.  Come to
think of it, I might do that next April, the Grand Unified PKI RFC:

Protocol Overview

This RFC standardises a universal PKI protocol which may be described using the
following procedure:

1. Go to your nearest supermarket and purchase a packet of alphabet soup (if
   you already have alphabet soup in your larder, you may skip this step).
   
2. Following the instructions on the packet, make sufficient alphabet soup to
   feed the members of your household.

3. Plunge a standards-conformant spoon into the soup and extract a sequence
   (3...MAX, MAX = 6) letters from the soup.  This is the name of the PKI
   protocol which this RFC standardises.

4. Eat the alphabet soup (after writing down the protocol name).

Protocol Details

This protocol consists of a single PDU:

PDU ::= SEQUENCE OF ANY

The protocol is thus trivial to implement, and universally applicable, since
anyone can implement it in whichever way they choose, and no-one can feel their
idea of how a PKI protocol should work has been unfairly excluded.  This makes
it equivalent to many other PKI protocols, but without requiring pages and
pages of tedious specification to distract the reader.

[etc - I'll leave the rest till late March, because the compile has just
 finished]

Peter.

Date: Wed, 18 Sep 2002 15:48:14 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
CC: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Michael,

> Denis Pinkas wrote:

> > RFC 3281 mandates only one GeneralName which MUST contain a non-empty
> > distinguished name in the directoryName field.

> So why use GeneralName at all?
> Why use an flexible CHOICE data type and then restrict its use to a
> single variant?

> => either the restriction in RFC 3281 is wrong or using the GeneralName
> does not make sense.

RFC 3281 is backwards compatible with ISO X.509. Since ISO X.509 was using
GeneralNames (see section 12.1 Attribute certificate structure) then 
RFC 3281 has done the same. Otherwise a defect report should be raised to 
ISO, ... which is something you could still do, through an ISO member. :-)

However, I wonder if ISO would accept to consider this as a "defect", 
since the syntax allows to do what you want (using a slightly more complex
encoding).

Denis

> If you want to use the flexibility of the CHOICE you have to define
> semantics of all options.
>
> I often repeat this important security advice:
> Keep things as simple as possible.
>
>
> Ciao, Michael.

Date: Wed, 18 Sep 2002 15:08:11 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Denis Pinkas wrote:
> 
> RFC 3281 mandates only one GeneralName which MUST contain a non-empty 
> distinguished name in the directoryName field.

So why use GeneralName at all?
Why use an flexible CHOICE data type and then restrict its use to a 
single variant?

=> either the restriction in RFC 3281 is wrong or using the GeneralName 
does not make sense.

If you want to use the flexibility of the CHOICE you have to define 
semantics of all options.

I often repeat this important security advice:
Keep things as simple as possible.

Ciao, Michael.

Date: Wed, 18 Sep 2002 23:04:51 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>RFC 3281 mandates only one GeneralName which MUST contain a non-empty
>distinguished name in the directoryName field.

In other words it has converted IssuerSerial into an awkward IssuerAnd-
SerialNumber, which is exactly option (1) that I mentioned.

It's like a self-fulfilling prophecy...

Peter.

Date: Wed, 18 Sep 2002 12:01:36 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Steve Hanna <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve,

> Denis Pinkas wrote:
> > > I would prefer an approach that gave a CA certificate to
> > > any user
> >
> > This is not RFC 3280 compliant. :-(
> >
> > > who might need to create a proxy certificate (with
> > > name constraints or other limitations to restrict the
> > > user's authority).
>
> RFC 3280 doesn't prohibit giving a CA certificate to a user,
> if the issuer of that certificate intends that certificates
> issued by the user should be honored. In fact, that's the
> proper way to indicate that the subject of a certificate
> is allowed to issue certificates. If you disagree, please
> point out something in RFC 3280 to justify your opinion.
>
> However, we are now headed down a rathole. I will try to
> refrain from extended discussions on this topic, since
> Steve Tuecke was just just trying to take a poll.

OK. In such a case, count my vote as a no vote (i.e. option #1).

:-(

Regards,

Denis

> Thanks,
> Steve

Date: Wed, 18 Sep 2002 11:54:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter,

> Denis Pinkas <[email-masked]> writes:
>
> > This is the one defined in RFC 2634, so I would not qualify it as a
> > "nonstandard variation".
>
> It's nonstandard in that even though there happens to be an RFC which mentions
> it (which probably applies to about 75% of everything computer-related, in one
> way or another), the standard that everyone uses is IssuerAndSerialNumber, not
> IssuerSerial (that is, just because it's mentioned in some standard doesn't
> make it "the standard", X9.31 vs.PKCS #1 is one of many, many examples).

> > Let us assume that the DN of the CA only contains CN=OpenCA.
> > [...]
>
> Well, what I really meant wasn't "Is it possible to hypothesise a situation in
> which it could in any way be concievable that IssuerSerial has any real use?"
> but rather "Are there real-world situations where this nonstandard construct is
> required?".
>
> I strongly suspect the answer is a resounding "No", since if anyone were to
> issue certs with incomplete issuer DNs as in the example you gave, civilisation
> would collapse... or at least the part of it which depends on PKI would... well
> OK, no-one would even notice, but in theory it would be bad.

:-)

> So my problem with IssuerSerial is that its nonstandard form doesn't solve any
> real-world problem, 

Since we do not have any name constraints for issuer names, a problem like
the one I described could happen, even if the name included additional
elements. The example was made very simple so that it could be easily
understood.

GeneralNames is defined in RFC 3280 (and X.509) as:

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

with:

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

So if the sequence is reduced to one element and the choice is the tag [4]
then it is easy to place a Name in that structure. I recognize that in most
cases, if the names of the CAs are well chosen, it will not be necessary 
to have more than one element.

Note also that RFC 3281 (maybe not yet a widely used standard) is defining
the issuer using:

            AttCertIssuer ::= CHOICE {
                 v1Form   GeneralNames,  -- MUST NOT be used in this
                                         -- profile
                 v2Form   [0] V2Form     -- v2 only
            }

            V2Form ::= SEQUENCE {
                 issuerName            GeneralNames  OPTIONAL,
                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
                   -- issuerName MUST be present in this profile
                   -- baseCertificateID and objectDigestInfo MUST NOT
                   -- be present in this profile
            }

So, if we had to extend OCSPv2 to check the revocation status of an
Attribute Certificate, this would be quite easy to do.

RFC 3281 mandates only one GeneralName which MUST contain a non-empty 
distinguished name in the directoryName field.

:-)

Denis

> and it opens up a whole raft of new problems because no-one
> knows what to do if it contains anything other than an IssuerAndSerialNumber
> encoded in an incompatible format.  The result will be one of two things:
>
> 1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
>    hacks wherever you have to convert it to the standard form.
>
> 2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
>    interoperates because no-one knows what to do with it.
>
> Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
> which removes any ambiguity and uses the standard form.  Option (2)... well,
> let's not go there.
>
> Peter.

Date: Wed, 18 Sep 2002 11:41:59 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter Gutmann wrote:
> So my problem with IssuerSerial is that its nonstandard form doesn't solve any
> real-world problem, and it opens up a whole raft of new problems because no-one
> knows what to do if it contains anything other than an IssuerAndSerialNumber
> encoded in an incompatible format.  The result will be one of two things:
> 
> 1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
>    hacks wherever you have to convert it to the standard form.
> 
> 2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
>    interoperates because no-one knows what to do with it.
> 
> Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
> which removes any ambiguity and uses the standard form.  Option (2)... well,
> let's not go there.

I have to strongly agree with Peter here.

Ciao, Michael.

From: "Marc Jadoul" <[email-masked]>
To: "Steve Hanna" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RFC 3280 error WRT rfc822Name
Date: Wed, 18 Sep 2002 10:41:56 +0200
Sender: [email-masked]

Seems a BIG problem to me!

May be RFC 3280 is wrong in his understanding of RFC 822.
But RFC 822 (or ...) is probably wrong in doing things so complex for End
Users.
And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.

Why is it like this in RFC 822 and successor?

Marc Jadoul

----- Original Message -----
From: "Steve Hanna" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 17, 2002 11:23 PM
Subject: RFC 3280 error WRT rfc822Name

>
> In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
>
>    Note that while upper and lower case letters are allowed in an
>    RFC 822 addr-spec, no significance is attached to the case.
>
> But RFC 822 says:
>
>         The only syntactic units which requires preservation of
>         case information are:
>
>                     -  text
>                     -  qtext
>                     -  dtext
>                     -  ctext
>                     -  quoted-pair
>                     -  local-part, except "Postmaster"
>
>         When matching any other syntactic unit, case is to be ignored.
>
> And RFC 2821 (the successor to RFC 821 and the companion
> to RFC 2822, which obsoletes RFC 822) is more explicit:
>
>    The local-part of a mailbox MUST BE treated as case sensitive.
>
> I have spoken to a few people about this and the consensus
> seems to be that RFC 3280 is wrong. When matching email
> addresses (such as when processing name constraints during
> certificate path validation), the local-part component of
> an email address must be treated as case-sensitive.
>
> If the members of these lists don't agree with this analysis,
> please speak up. Otherwise, I expect that this will be fixed
> in the successor to RFC 3280. Note that I don't think this
> is an especially big deal. I just thought people would want
> to know of the problem ASAP.
>
> Note also that many email servers don't treat local-part as
> case-sensitive. But some do. There's no way for a certificate
> processing system to know whether [email-masked] is
> actually the same mailbox as [email-masked]. So the
> certificate processing system must treat them as different.
> At least, that's the rationale for this rule.
>
> Thanks,
>
> Steve Hanna
> Sun Microsystems, Inc.
>

Date: Wed, 18 Sep 2002 18:18:23 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>This is the one defined in RFC 2634, so I would not qualify it as a
>"nonstandard variation".

It's nonstandard in that even though there happens to be an RFC which mentions
it (which probably applies to about 75% of everything computer-related, in one
way or another), the standard that everyone uses is IssuerAndSerialNumber, not
IssuerSerial (that is, just because it's mentioned in some standard doesn't
make it "the standard", X9.31 vs.PKCS #1 is one of many, many examples).

>Let us assume that the DN of the CA only contains CN=OpenCA.
>[...]

Well, what I really meant wasn't "Is it possible to hypothesise a situation in
which it could in any way be concievable that IssuerSerial has any real use?"
but rather "Are there real-world situations where this nonstandard construct is
required?".

I strongly suspect the answer is a resounding "No", since if anyone were to
issue certs with incomplete issuer DNs as in the example you gave, civilisation
would collapse... or at least the part of it which depends on PKI would... well
OK, no-one would even notice, but in theory it would be bad.

So my problem with IssuerSerial is that its nonstandard form doesn't solve any
real-world problem, and it opens up a whole raft of new problems because no-one
knows what to do if it contains anything other than an IssuerAndSerialNumber
encoded in an incompatible format.  The result will be one of two things:

1. Everyone treats it as a weird IssuerAndSerialNumber, requiring ugly code
   hacks wherever you have to convert it to the standard form.

2. People pile random (non-IssuerAndSerialNumber) junk into it, and nothing
   interoperates because no-one knows what to do with it.

Option (1) is handled much more cleanly by just using IssuerAndSerialNumber,
which removes any ambiguity and uses the standard form.  Option (2)... well,
let's not go there.

Peter.

Date: Tue, 17 Sep 2002 16:27:58 -0700 (PDT)
From: [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
To: [email-masked]
Cc: Steve Hanna <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> That's pretty interesting....I hope I'm the only one surprised by this
> requirement.

This requirement is well understood by those of us who work on email software.
Any package that fails to support it gets in trouble sooner or later. Indeed,
software that preserves case but isn't capable of supporting case sensitivity
for domains it has administrative control over can be problematic. I've seen
software sales won or lost over this issue.

>  At the end of the same paragraph in RFC 2821 is the
> "loophole" that I think most people will invoke to get around this new
> "requirement":

> ...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

> I anticipate that this means, for all practical matters, that the "MUST"
> part of case sensitivity will be ignored by enough vendors that we
> should plan on treating the mail local-part as case insensitive anyhow.
>  Personally, I think it makes sense to treat mailbox strings as case
> insensitive, but that's just me speaking.

The rule is fairly simple: If you have administrative authority for the domain
you are entitled to use the local-part in any way you like, including but not
limited to igoring case. If, on the other hand, you do not have administrative
authority, you are not entitled to do this. And if you do, know that there real
domain exist where case matters and things will break.

				Ned

Date: Tue, 17 Sep 2002 15:36:59 -0700
From: [email-masked] (Bill Burns)
To: Steve Hanna <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

Steve Hanna wrote:

>In section 4.2.1.7, RFC 3280 (and RFC 2459) says:
>
>   Note that while upper and lower case letters are allowed in an
>   RFC 822 addr-spec, no significance is attached to the case.
>
>But RFC 822 says:
>
>        The only syntactic units which requires preservation of
>        case information are:
>
>                    -  text
>                    -  qtext
>                    -  dtext
>                    -  ctext
>                    -  quoted-pair
>                    -  local-part, except "Postmaster"
>
>        When matching any other syntactic unit, case is to be ignored.
>
>And RFC 2821 (the successor to RFC 821 and the companion
>to RFC 2822, which obsoletes RFC 822) is more explicit:
>
>   The local-part of a mailbox MUST BE treated as case sensitive.
>
>I have spoken to a few people about this and the consensus
>seems to be that RFC 3280 is wrong. When matching email
>addresses (such as when processing name constraints during
>certificate path validation), the local-part component of
>an email address must be treated as case-sensitive.
>
>If the members of these lists don't agree with this analysis,
>please speak up. Otherwise, I expect that this will be fixed
>in the successor to RFC 3280. Note that I don't think this
>is an especially big deal. I just thought people would want
>to know of the problem ASAP.
>
>Note also that many email servers don't treat local-part as
>case-sensitive. But some do. There's no way for a certificate
>processing system to know whether [email-masked] is
>actually the same mailbox as [email-masked]. So the
>certificate processing system must treat them as different.
>At least, that's the rationale for this rule.
>
>Thanks,
>
>Steve Hanna
>Sun Microsystems, Inc.
>  
>
Thanks, Steve.

That's pretty interesting....I hope I'm the only one surprised by this 
requirement.  At the end of the same paragraph in RFC 2821 is the 
"loophole" that I think most people will invoke to get around this new 
"requirement":

...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

I anticipate that this means, for all practical matters, that the "MUST" 
part of case sensitivity will be ignored by enough vendors that we 
should plan on treating the mail local-part as case insensitive anyhow. 
 Personally, I think it makes sense to treat mailbox strings as case 
insensitive, but that's just me speaking.

bill

Importance: Normal
Subject: Re: What happened to the OCSPv2 draft?
From: "Florian B Oelmaier" <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Date: Wed, 18 Sep 2002 00:01:50 +0200
Sender: [email-masked]

Date: Tue, 17 Sep 2002 17:23:52 -0400
From: Steve Hanna <[email-masked]>
To: [email-masked], [email-masked]
Subject: RFC 3280 error WRT rfc822Name
Sender: [email-masked]

In section 4.2.1.7, RFC 3280 (and RFC 2459) says:

   Note that while upper and lower case letters are allowed in an
   RFC 822 addr-spec, no significance is attached to the case.

But RFC 822 says:

        The only syntactic units which requires preservation of
        case information are:

                    -  text
                    -  qtext
                    -  dtext
                    -  ctext
                    -  quoted-pair
                    -  local-part, except "Postmaster"

        When matching any other syntactic unit, case is to be ignored.

And RFC 2821 (the successor to RFC 821 and the companion
to RFC 2822, which obsoletes RFC 822) is more explicit:

   The local-part of a mailbox MUST BE treated as case sensitive.

I have spoken to a few people about this and the consensus
seems to be that RFC 3280 is wrong. When matching email
addresses (such as when processing name constraints during
certificate path validation), the local-part component of
an email address must be treated as case-sensitive.

If the members of these lists don't agree with this analysis,
please speak up. Otherwise, I expect that this will be fixed
in the successor to RFC 3280. Note that I don't think this
is an especially big deal. I just thought people would want
to know of the problem ASAP.

Note also that many email servers don't treat local-part as
case-sensitive. But some do. There's no way for a certificate
processing system to know whether [email-masked] is
actually the same mailbox as [email-masked]. So the
certificate processing system must treat them as different.
At least, that's the rationale for this rule.

Thanks,

Steve Hanna
Sun Microsystems, Inc.

From: "Housley, Russ" <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Date: Tue, 17 Sep 2002 16:21:10 -0400
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Paul:

People complained about these imports.  The ASN.1 modules associated with 
the X.500 series of recommendations are considered harder to obtain.  They 
also have a much more complex import structure.  Due to this feedback from 
implementors, RFC 3369 (the son-of-rfc2630) imports from the PKIX ASN.1 
modules.

Russ

At 12:55 PM 9/17/2002 -0700, Paul Hoffman / IMC wrote:

>At 2:17 PM +0200 9/17/02, Denis Pinkas wrote:
>>Paul Hoffman, the editor, would certainly be in a better position to
>>respond. Since RFC 2634 was created after RFC 2630 there must be a good
>>reason.
>
>They were issued at the same time. 2630 chose to continue importing "Name" 
>from X.501; 2634 chose to import GeneralNames from PKIX.
>
>2630 is obviously much more widely implemented than 2634.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Tue, 17 Sep 2002 12:55:35 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

At 2:17 PM +0200 9/17/02, Denis Pinkas wrote:
>Paul Hoffman, the editor, would certainly be in a better position to
>respond. Since RFC 2634 was created after RFC 2630 there must be a good
>reason.

They were issued at the same time. 2630 chose to continue importing 
"Name" from X.501; 2634 chose to import GeneralNames from PKIX.

2630 is obviously much more widely implemented than 2634.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Housley, Russ" <[email-masked]>
To: Dean Adams <[email-masked]>
Cc: [email-masked]
Date: Tue, 17 Sep 2002 14:58:00 -0400
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Dean:

I do not envision the use of proxy certificates in S/MIME.  The document 
that we are discussing provides a context for the proxy.  Perhaps the title 
should make this context more clear.

Russ

At 02:52 PM 9/17/2002 +0100, Dean Adams wrote:

>Hi Denis,
>         Thanks for the pointer.  I've taken a look at your presentation which
>proposes an alternative viable approach for achieving what I see as a real
>business need to be fulfilled. What feedback and support have you had for
>this proposal so far?
>
>My question is: would a solution based on the Proxy Certificate be more
>likely to be supported by S/MIME client apps than one based on the use of
>attribute certificates?  I have the feeling that in many S/MIME client
>applications, the additional effort to support proxy certificates would be
>less than that required for attribute certificates.  I do not develop such
>client applications and am therefore not best qualified to comment.  Whilst
>one approach may be more technically or architecturally pure and correct
>than another, my chief interest is in seeing these capabilities being
>reflected in real commercial products.
>
>Comments welcomed, particularly from developers of commercial S/MIME client
>application.
>
>         Regards
>         Dean
>
>____________________________________________________________
>Dean Adams               mobile:         +44 (0)7989 385914
>Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
>49 Whitehall             Office Tel:     +44 (0)20 7451 1490
>London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
>email: [email-masked]    Web: http://www.trustis.com
>____________________________________________________________
>The information in this message is confidential.  It is intended solely for
>the addressee.  Access to this message by anyone else is unauthorised.  If
>you are not the intended recipient, any disclosure, copying, distribution or
>any action taken or omitted to be taken in reliance on it, is prohibited and
>may be unlawful.
>
>Any attachments to this message have been checked for viruses, but please
>rely on your own virus checker and procedures.
>
>If you contact us by e-mail, we may store your name and address to
>facilitate communications.
>
>
>-----Original Message-----
>From: Denis Pinkas [mailto:[email-masked]]
>Sent: 17 September 2002 13:19
>To: Dean Adams
>Cc: [email-masked]
>Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
>
>
>Hi Dean,
>
>Nice to "meet" you again, not face-to-face but on the net.
>
> > Hi,
> >         Sorry for not following your rules for possible answers, but at
>the moment
> > I would prefer to reply with a Provisional vote for #3, since I see a real
> > business need for proxy support in an S/MIME environment, (e.g. an
>assistant
> > signing emails and attachments on behalf of his/her boss).  This is
> > something that many folks have asked if it is possible with PKI since
> > current paper based practices involve some of this.
>
>I wonder if the proxy certificate document is the right answer to your very
>valid
>concern.
>
>The proxy certificate document is targeted for impersonation for access
>control
>but not for signature in an S/MIME context.
>
>If your are interested in signature delegation in an S/MIME context, please
>refer to
>the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
>2001)
>where I was considering using of profile of an Attribute Certificate. The
>title of
>that presentation is "Signature delegation" in the slides section from the
>S/MIME WG.
>
> > The provisional nature of my vote stems from the fact that the
>specification
> > (as I have just read it from the PKIX site) does not mention anywhere the
> > potential use of a proxy certificate in an S/MIME setting.  Furthermore,
>the
> > spec would seem to preclude the use of a proxy certificate in an S/MIME
> > setting since the spec sates that "The subjectAltName extension MUST NOT
>be
> > present in a Proxy Certificate".
> >
> > Given my very brief reading of this spec, it is likely that I have got the
> > wrong idea and that S/MIME usage can indeed be supported.  In that case I
> > apologise, but would appreciate anyone explaining the situation.
>
>For the time being I would not count your provisional vote for #3.
>
>:-)
>
>Regards,
>
>Denis
>
>
> >
> >         Thanks
> >         Dean Adams
> >
> > ____________________________________________________________
> > Dean Adams               mobile:         +44 (0)7989 385914
> > Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
> > 49 Whitehall             Office Tel:     +44 (0)20 7451 1490
> > London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
> > email: [email-masked]    Web: http://www.trustis.com
> > ____________________________________________________________
> > The information in this message is confidential.  It is intended solely
>for
> > the addressee.  Access to this message by anyone else is unauthorised.  If
> > you are not the intended recipient, any disclosure, copying, distribution
>or
> > any action taken or omitted to be taken in reliance on it, is prohibited
>and
> > may be unlawful.
> >
> > Any attachments to this message have been checked for viruses, but please
> > rely on your own virus checker and procedures.
> >
> > If you contact us by e-mail, we may store your name and address to
> > facilitate communications.
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Steve Tuecke
> > Sent: 16 September 2002 20:42
> > To: [email-masked]
> > Cc: Steve Tuecke
> > Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
> >
> > All,
> >
> > A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> > PKIX.  Russ argued against this, which led to posing the following
> > straw-poll question:
> >
> > >Should PKIX sanction the advancement of a proxy cert draft based on the
> > >current fundamental approach?  We can argue about the details more later,
> > >but the fundamental approach at issue is whether it is reasonable to use
> > >end-entity public key certificates to sign proxy certificates. Possible
> > >answers are:
> > >   1) No.
> > >   2) Yes, but only as Informational Track.
> > >   3) Yes, as Standards Track.
> >
> > There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> > suggested forming a new working group, which I would put in the #1
> > category.  Denis Pinkas responded, but did not explicitly vote for one of
> > these choices -- his closest statement to a vote was 'I do not have [a
> > problem with using end-entity public key certificates to sign proxy
> > certificates] as long as the draft is using everywhere "proxy certificate"
> > and is NOT using the terminology "public key certificate"'.
> >
> > So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> > apathy.  Anybody else care to weigh in on this issue?
> >
> > -Steve
> >
> > At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> > >Answer: Start a new group
> > >
> > >PKIX was formed to do one thing and has become a standing committee that
> > >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> > >
> > >I would much prefer to see the group split into two. Continuing PKIX
>would
> > >be tasked with simply moving the current RFCs through the standards track
> > to
> > >Draft and Standard. PKIX-EXT would be tasked with developing extensions
>to
> > >PKIX where necessary.
> > >
> > >
> > >                 Phill

Content-return: allowed
Date: Tue, 17 Sep 2002 11:39:38 -0700
From: Peter Williams <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
To: "[email-masked]' '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.

--Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)
Content-type: text/plain; charset="iso-8859-1"

Phil (Griffen),

We could try an exeriment to apply this technique. LDAP
is showing its age; its now harder to implement
than good old DAP. XML directory protocols are growing up very
fast, and support signed operations used in
Allied Directories, unlike LDAP.

What we could do this:  If we take the remote operation 
specification in X.511 we could use your
tool to produce a conformance checker for use
in ACP 133 Border DSAs that support 3 ports: DAP, 
LDAP, and XML-encoded. The border guard would
use XSL filters to control information
dissemnation, with greater granularity,
and using commodity implementation baseline.

We could probably work together to get some military 
research money to make a prototyye, building
on the WDSL for directory services, 
http://www.oasis-open.org/cover/dsml.html. DSML v2
encode LDAP request/responses as XML document
fragments. In this way all the military architectural
work of LDAP can be reused, with a better tool set capable
of generating automatic code, for
field replacement as standards evolve.

-----Original Message-----
From: Hallam-Baker, Phillip
To: [email-masked]'; Hallam-Baker, Phillip; [email-masked];
[email-masked]; [email-masked]
Sent: 9/16/02 8:04 AM
Subject: RE: What happened to the OCSPv2 draft?

Has any party commercial or non-comercial endorsed the 
proposed 'standard' and committed to supporting it?

It is one thing to get a bunch of people to agree to
a proposal, quite another to persuade an industry to
deploy.

I fail to see the value of an XML expression of deployed
X.509 semantics. I fail to see the value of an ASN.1
encoding to rival deployed XML specifications.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 4:19 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value. Clearly messages can be stored and transferrd in DER
>  (which is not a particularly compact ASN.1 encoding, but  
> which enjoys
>  tools are cheap  and readily available) and exploded into 
> XML markup in 
> resource rich environments.
> 
> This is the thrust of the OASIS XML Common Biometric Format, the 2002
> revision of the X9.84 biometric information management and security , 
> the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
> Trusted Time 
> Stamp standards. It is also the core of the NWI proposal in 
> ISO TC68/SC2 
> based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> compressed domain certificate standard that moved forward in 
> ISO this week.
> If passed, this will result in a DER encoded certificate that is much
> smaller
> than the X.509 certificate format it is based on, and a 
> completely XML 
> certificate as well. The possibilities this will create to 
> stir the pot
> will be
>  interesting.
>  
> The idea of this approach is compelling for several reasons. 
> It provides a
> migration path into the XML space for ASN.1 defined specifications, it
> allows
> systems to be built  like my Biolojava tool kit that provide 
> support  for
> both XML
> aware and ASN.1 aware applications, and it provides 
> compression for XML
> values. 
> 
> But the really sweet  fallout of this is the simplicity of the XML
> signature 
> processing. It turns out to be almost equivalent  to the processing
> description used currently for DER in the IETF SMIME standard. 
> Anyone that can do SignedData using DER can, without nearly a
> thought, do the same with XML markup and leverage the browser.
> 
> And there are tools like mine emerging to support  these concepts, and
> standards that will use them.
> 
> Phil

--Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)
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.2653.12">
<TITLE>RE: What happened to the OCSPv2 draft?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Phil (Griffen),</FONT>
</P>

<P><FONT SIZE=3D2>We could try an exeriment to apply this technique. =
LDAP</FONT>
<BR><FONT SIZE=3D2>is showing its age; its now harder to =
implement</FONT>
<BR><FONT SIZE=3D2>than good old DAP. XML directory protocols are =
growing up very</FONT>
<BR><FONT SIZE=3D2>fast, and support signed operations used in</FONT>
<BR><FONT SIZE=3D2>Allied Directories, unlike LDAP.</FONT>
</P>

<P><FONT SIZE=3D2>What we could do this:&nbsp; If we take the remote =
operation </FONT>
<BR><FONT SIZE=3D2>specification in X.511 we could use your</FONT>
<BR><FONT SIZE=3D2>tool to produce a conformance checker for use</FONT>
<BR><FONT SIZE=3D2>in ACP 133 Border DSAs that support 3 ports: DAP, =
</FONT>
<BR><FONT SIZE=3D2>LDAP, and XML-encoded. The border guard would</FONT>
<BR><FONT SIZE=3D2>use XSL filters to control information</FONT>
<BR><FONT SIZE=3D2>dissemnation, with greater granularity,</FONT>
<BR><FONT SIZE=3D2>and using commodity implementation baseline.</FONT>
</P>

<P><FONT SIZE=3D2>We could probably work together to get some military =
</FONT>
<BR><FONT SIZE=3D2>research money to make a prototyye, building</FONT>
<BR><FONT SIZE=3D2>on the WDSL for directory services, </FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.oasis-open.org/cover/dsml.html" =
TARGET=3D"_blank">http://www.oasis-open.org/cover/dsml.html</A>. DSML =
v2</FONT>
<BR><FONT SIZE=3D2>encode LDAP request/responses as XML document</FONT>
<BR><FONT SIZE=3D2>fragments. In this way all the military =
architectural</FONT>
<BR><FONT SIZE=3D2>work of LDAP can be reused, with a better tool set =
capable</FONT>
<BR><FONT SIZE=3D2>of generating automatic code, for</FONT>
<BR><FONT SIZE=3D2>field replacement as standards evolve.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Hallam-Baker, Phillip</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]'; Hallam-Baker, Phillip; =
[email-masked]; [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Sent: 9/16/02 8:04 AM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: What happened to the OCSPv2 =
draft?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Has any party commercial or non-comercial endorsed =
the </FONT>
<BR><FONT SIZE=3D2>proposed 'standard' and committed to supporting =
it?</FONT>
</P>

<P><FONT SIZE=3D2>It is one thing to get a bunch of people to agree =
to</FONT>
<BR><FONT SIZE=3D2>a proposal, quite another to persuade an industry =
to</FONT>
<BR><FONT SIZE=3D2>deploy.</FONT>
</P>

<P><FONT SIZE=3D2>I fail to see the value of an XML expression of =
deployed</FONT>
<BR><FONT SIZE=3D2>X.509 semantics. I fail to see the value of an =
ASN.1</FONT>
<BR><FONT SIZE=3D2>encoding to rival deployed XML =
specifications.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Phill</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, September 13, 2002 4:19 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: What happened to the OCSPv2 =
draft?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Of course, there already is a more efficient =
encoding for XML</FONT>
<BR><FONT SIZE=3D2>&gt; markup. The example at <A =
HREF=3D"http://asn-1.com/EncodeBiometricSyntaxSets.htm" =
TARGET=3D"_blank">http://asn-1.com/EncodeBiometricSyntaxSets.htm</A></FO=
NT>
<BR><FONT SIZE=3D2>&gt; shows that an X9.84/XCBF object can be encoded =
in 500+ bytes in XML,</FONT>
<BR><FONT SIZE=3D2>&gt; and that exactly the same abstract values can =
be encoded in </FONT>
<BR><FONT SIZE=3D2>&gt; 50+ bytes in</FONT>
<BR><FONT SIZE=3D2>&gt; DER. The obvious conclusion is that for every =
canonical DER </FONT>
<BR><FONT SIZE=3D2>&gt; value there</FONT>
<BR><FONT SIZE=3D2>&gt; is a canonical XER encoding that yields an XMl =
markup </FONT>
<BR><FONT SIZE=3D2>&gt; representation of </FONT>
<BR><FONT SIZE=3D2>&gt; that same value. Clearly messages can be stored =
and transferrd in DER</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; (which is not a particularly compact =
ASN.1 encoding, but&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; which enjoys</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; tools are cheap&nbsp; and readily =
available) and exploded into </FONT>
<BR><FONT SIZE=3D2>&gt; XML markup in </FONT>
<BR><FONT SIZE=3D2>&gt; resource rich environments.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This is the thrust of the OASIS XML Common =
Biometric Format, the 2002</FONT>
<BR><FONT SIZE=3D2>&gt; revision of the X9.84 biometric information =
management and security , </FONT>
<BR><FONT SIZE=3D2>&gt; the X9.96 XML Cryptographic Message Syntax, and =
the&nbsp; X9.95 </FONT>
<BR><FONT SIZE=3D2>&gt; Trusted Time </FONT>
<BR><FONT SIZE=3D2>&gt; Stamp standards. It is also the core of the NWI =
proposal in </FONT>
<BR><FONT SIZE=3D2>&gt; ISO TC68/SC2 </FONT>
<BR><FONT SIZE=3D2>&gt; based on the XMLEncoding Rules and the schema =
defined in the ASC X9.68</FONT>
<BR><FONT SIZE=3D2>&gt; compressed domain certificate standard that =
moved forward in </FONT>
<BR><FONT SIZE=3D2>&gt; ISO this week.</FONT>
<BR><FONT SIZE=3D2>&gt; If passed, this will result in a DER encoded =
certificate that is much</FONT>
<BR><FONT SIZE=3D2>&gt; smaller</FONT>
<BR><FONT SIZE=3D2>&gt; than the X.509 certificate format it is based =
on, and a </FONT>
<BR><FONT SIZE=3D2>&gt; completely XML </FONT>
<BR><FONT SIZE=3D2>&gt; certificate as well. The possibilities this =
will create to </FONT>
<BR><FONT SIZE=3D2>&gt; stir the pot</FONT>
<BR><FONT SIZE=3D2>&gt; will be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; interesting.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; The idea of this approach is compelling for =
several reasons. </FONT>
<BR><FONT SIZE=3D2>&gt; It provides a</FONT>
<BR><FONT SIZE=3D2>&gt; migration path into the XML space for ASN.1 =
defined specifications, it</FONT>
<BR><FONT SIZE=3D2>&gt; allows</FONT>
<BR><FONT SIZE=3D2>&gt; systems to be built&nbsp; like my Biolojava =
tool kit that provide </FONT>
<BR><FONT SIZE=3D2>&gt; support&nbsp; for</FONT>
<BR><FONT SIZE=3D2>&gt; both XML</FONT>
<BR><FONT SIZE=3D2>&gt; aware and ASN.1 aware applications, and it =
provides </FONT>
<BR><FONT SIZE=3D2>&gt; compression for XML</FONT>
<BR><FONT SIZE=3D2>&gt; values. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But the really sweet&nbsp; fallout of this is =
the simplicity of the XML</FONT>
<BR><FONT SIZE=3D2>&gt; signature </FONT>
<BR><FONT SIZE=3D2>&gt; processing. It turns out to be almost =
equivalent&nbsp; to the processing</FONT>
<BR><FONT SIZE=3D2>&gt; description used currently for DER in the IETF =
SMIME standard. </FONT>
<BR><FONT SIZE=3D2>&gt; Anyone that can do SignedData using DER can, =
without nearly a</FONT>
<BR><FONT SIZE=3D2>&gt; thought, do the same with XML markup and =
leverage the browser.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; And there are tools like mine emerging to =
support&nbsp; these concepts, and</FONT>
<BR><FONT SIZE=3D2>&gt; standards that will use them.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Phil</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_dTtmauWA1KVizztTmFy1Bg)--

Date: Tue, 17 Sep 2002 13:19:30 -0400
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: [email-masked]
CC: [email-masked]
Subject: Re: support for multiple authorityKeyID OIDs
Sender: [email-masked]

The X.509 certificate extension OID arc, 2.5.29 can be
referenced in several formats on the ASN.1 Information
site, http://asn1.elibel.tm.fr/en/oid/index.htm.

The X.500 series module database maintained by the
ITU-T, http://www.itu.int/ITU-T/asn1/database/itu-t/x/,
has detailed information taken from the Directory
standards.

See especially the bottom of the X.509 module at

http://www.itu.int/ITU-T/asn1/database/itu-t/x/
    x509/1997/CertificateExtensions.asn

and notice that { id-ce 2 } is no longer used:

--  The following OBJECT IDENTIFIERS are not used by this
--  Specification:
--  {id-ce 2}, {id-ce 3}, {id-ce 4}, {id-ce 5}, {id-ce 6},
--  {id-ce 7}, {id-ce 8}, {id-ce 10}, {id-ce 11}, {id-ce 12},
--  {id-ce 13}, {id-ce 22}, {id-ce 25}, {id-ce 26}

Phil

[email-masked] wrote:

> 
> I have found references that identify 2 OIDs that have been assigned to 
> authorityKeyID and was wondering if applications still need to support 
> both.   The reference, http://www.alvestrand.no/objectid/2.5.29.html, 
>  indicated the first (2.5.29.2) might be obsolete.  I have been unable 
> to determine how to access an official listing for this branch but did 
> see Peter Gutmann's dumpasn1.config confirm the deprecation. Can anyone 
> point me in the right direction for the officially maintained list?  I 
> saw that Russ Housley maintains the PKIX OIDs but this value seems to be 
> under others control.
> 
> Do any CAs still issue using 2.5.29.1 or is everyone currently using 
> 2.5.29.35?  
> 
> Do any certs still exist as valid that had 2.5.29.1 values set?
> 
> Thanks,
> Chris Ryan
> Security and Technology Services
> Ernst & Young
> 
> ________________________________________________________________________
> The information contained in this message may be privileged and 
> confidential and protected from disclosure. If the reader of this 
> message is not the intended recipient, or an employee or agent 
> responsible for delivering this message to the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of 
> this communication is strictly prohibited. If you have received this 
> communication in error, please notify us immediately by replying to the 
> message and deleting it from your computer. Thank you. Ernst & Young LLP

Date: Tue, 17 Sep 2002 11:54:45 -0400
From: Steve Hanna <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Denis Pinkas wrote:
> > I would prefer an approach that gave a CA certificate to
> > any user
> 
> This is not RFC 3280 compliant. :-(
> 
> > who might need to create a proxy certificate (with
> > name constraints or other limitations to restrict the
> > user's authority).

RFC 3280 doesn't prohibit giving a CA certificate to a user,
if the issuer of that certificate intends that certificates
issued by the user should be honored. In fact, that's the
proper way to indicate that the subject of a certificate
is allowed to issue certificates. If you disagree, please
point out something in RFC 3280 to justify your opinion.

However, we are now headed down a rathole. I will try to
refrain from extended discussions on this topic, since
Steve Tuecke was just just trying to take a poll.

Thanks,

Steve

Date: Tue, 17 Sep 2002 17:55:53 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Dean Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Dean,

>From your very last question, I fear that you are on the wrong mailing list.
You should use [email-masked]

> Hi Denis,
>         Thanks for the pointer.  I've taken a look at your presentation which
> proposes an alternative viable approach for achieving what I see as a real
> business need to be fulfilled. What feedback and support have you had for
> this proposal so far?

The idea came during a lunch at Salt Lake City with some well known experts.

>From an idea to a specification and finally a product, this takes a long time.

> My question is: would a solution based on the Proxy Certificate be more
> likely to be supported by S/MIME client apps than one based on the use of
> attribute certificates?  I have the feeling that in many S/MIME client
> applications, the additional effort to support proxy certificates would be
> less than that required for attribute certificates.

The proposal is to use the format of an Attribute Certificate without the
burden to deploy an Attribute Authority.

Note also that the rule to verify such a delegation cannot be the rule to
verify a PKC, hence one of the main motivations for the proxy certificate
vanishes.

Denis

> I do not develop such
> client applications and am therefore not best qualified to comment.  Whilst
> one approach may be more technically or architecturally pure and correct
> than another, my chief interest is in seeing these capabilities being
> reflected in real commercial products.
>
> Comments welcomed, particularly from developers of commercial S/MIME client
> application.
>
>         Regards
>         Dean
>
> ____________________________________________________________
> Dean Adams               mobile:         +44 (0)7989 385914
> Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
> 49 Whitehall             Office Tel:     +44 (0)20 7451 1490
> London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
> email: [email-masked]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended solely for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying, distribution or
> any action taken or omitted to be taken in reliance on it, is prohibited and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: 17 September 2002 13:19
> To: Dean Adams
> Cc: [email-masked]
> Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
>
> Hi Dean,
>
> Nice to "meet" you again, not face-to-face but on the net.
>
> > Hi,
> >         Sorry for not following your rules for possible answers, but at
> the moment
> > I would prefer to reply with a Provisional vote for #3, since I see a real
> > business need for proxy support in an S/MIME environment, (e.g. an
> assistant
> > signing emails and attachments on behalf of his/her boss).  This is
> > something that many folks have asked if it is possible with PKI since
> > current paper based practices involve some of this.
>
> I wonder if the proxy certificate document is the right answer to your very
> valid
> concern.
>
> The proxy certificate document is targeted for impersonation for access
> control
> but not for signature in an S/MIME context.
>
> If your are interested in signature delegation in an S/MIME context, please
> refer to
> the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
> 2001)
> where I was considering using of profile of an Attribute Certificate. The
> title of
> that presentation is "Signature delegation" in the slides section from the
> S/MIME WG.
>
> > The provisional nature of my vote stems from the fact that the
> specification
> > (as I have just read it from the PKIX site) does not mention anywhere the
> > potential use of a proxy certificate in an S/MIME setting.  Furthermore,
> the
> > spec would seem to preclude the use of a proxy certificate in an S/MIME
> > setting since the spec sates that "The subjectAltName extension MUST NOT
> be
> > present in a Proxy Certificate".
> >
> > Given my very brief reading of this spec, it is likely that I have got the
> > wrong idea and that S/MIME usage can indeed be supported.  In that case I
> > apologise, but would appreciate anyone explaining the situation.
>
> For the time being I would not count your provisional vote for #3.
>
> :-)
>
> Regards,
>
> Denis
>
> >
> >         Thanks
> >         Dean Adams
> >
> > ____________________________________________________________
> > Dean Adams               mobile:         +44 (0)7989 385914
> > Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
> > 49 Whitehall             Office Tel:     +44 (0)20 7451 1490
> > London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
> > email: [email-masked]    Web: http://www.trustis.com
> > ____________________________________________________________
> > The information in this message is confidential.  It is intended solely
> for
> > the addressee.  Access to this message by anyone else is unauthorised.  If
> > you are not the intended recipient, any disclosure, copying, distribution
> or
> > any action taken or omitted to be taken in reliance on it, is prohibited
> and
> > may be unlawful.
> >
> > Any attachments to this message have been checked for viruses, but please
> > rely on your own virus checker and procedures.
> >
> > If you contact us by e-mail, we may store your name and address to
> > facilitate communications.
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Steve Tuecke
> > Sent: 16 September 2002 20:42
> > To: [email-masked]
> > Cc: Steve Tuecke
> > Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
> >
> > All,
> >
> > A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> > PKIX.  Russ argued against this, which led to posing the following
> > straw-poll question:
> >
> > >Should PKIX sanction the advancement of a proxy cert draft based on the
> > >current fundamental approach?  We can argue about the details more later,
> > >but the fundamental approach at issue is whether it is reasonable to use
> > >end-entity public key certificates to sign proxy certificates. Possible
> > >answers are:
> > >   1) No.
> > >   2) Yes, but only as Informational Track.
> > >   3) Yes, as Standards Track.
> >
> > There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> > suggested forming a new working group, which I would put in the #1
> > category.  Denis Pinkas responded, but did not explicitly vote for one of
> > these choices -- his closest statement to a vote was 'I do not have [a
> > problem with using end-entity public key certificates to sign proxy
> > certificates] as long as the draft is using everywhere "proxy certificate"
> > and is NOT using the terminology "public key certificate"'.
> >
> > So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> > apathy.  Anybody else care to weigh in on this issue?
> >
> > -Steve
> >
> > At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> > >Answer: Start a new group
> > >
> > >PKIX was formed to do one thing and has become a standing committee that
> > >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> > >
> > >I would much prefer to see the group split into two. Continuing PKIX
> would
> > >be tasked with simply moving the current RFCs through the standards track
> > to
> > >Draft and Standard. PKIX-EXT would be tasked with developing extensions
> to
> > >PKIX where necessary.
> > >
> > >
> > >                 Phill

To: [email-masked]
Subject: support for multiple authorityKeyID OIDs
From: [email-masked]
Date: Tue, 17 Sep 2002 10:44:16 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 004FEDF285256C37_=
Content-Type: text/plain; charset="us-ascii"

I have found references that identify 2 OIDs that have been assigned to 
authorityKeyID and was wondering if applications still need to support 
both.   The reference, http://www.alvestrand.no/objectid/2.5.29.html, 
indicated the first (2.5.29.2) might be obsolete.  I have been unable to 
determine how to access an official listing for this branch but did see 
Peter Gutmann's dumpasn1.config confirm the deprecation. Can anyone point 
me in the right direction for the officially maintained list?  I saw that 
Russ Housley maintains the PKIX OIDs but this value seems to be under 
others control.

Do any CAs still issue using 2.5.29.1 or is everyone currently using 
2.5.29.35? 

Do any certs still exist as valid that had 2.5.29.1 values set?

Thanks,
Chris Ryan
Security and Technology Services
Ernst & Young

________________________________________________________________________
The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP

--=_alternative 004FEDF285256C37_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">I have found references that identify 2 OIDs that have been assigned to authorityKeyID and was wondering if applications still need to support both. &nbsp; The reference, http://www.alvestrand.no/objectid/2.5.29.html, &nbsp;indicated the first (2.5.29.2) might be obsolete. &nbsp;I have been unable to determine how to access an official listing for this branch but did see Peter Gutmann's dumpasn1.config confirm the deprecation. Can anyone point me in the right direction for the officially maintained list? &nbsp;I saw that Russ Housley maintains the PKIX OIDs but this value seems to be under others control.</font>
<br>
<br><font size=2 face="sans-serif">Do any CAs still issue using 2.5.29.1 or is everyone currently using 2.5.29.35? &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Do any certs still exist as valid that had 2.5.29.1 values set?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Chris Ryan<br>
Security and Technology Services<br>
Ernst &amp; Young<br>
</font><font face="Helv" size=3 color=#000000 ></font><br><font face="Helv" size=3 color=#000000 >________________________________________________________________________</font><br><font face="Helv" size=3 color=#000000 >The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.  Ernst & Young LLP</font><br>
--=_alternative 004FEDF285256C37_=--

From: "Dean Adams" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Tue, 17 Sep 2002 14:52:57 +0100
Importance: Normal
Sender: [email-masked]

Hi Denis,
	Thanks for the pointer.  I've taken a look at your presentation which
proposes an alternative viable approach for achieving what I see as a real
business need to be fulfilled. What feedback and support have you had for
this proposal so far?

My question is: would a solution based on the Proxy Certificate be more
likely to be supported by S/MIME client apps than one based on the use of
attribute certificates?  I have the feeling that in many S/MIME client
applications, the additional effort to support proxy certificates would be
less than that required for attribute certificates.  I do not develop such
client applications and am therefore not best qualified to comment.  Whilst
one approach may be more technically or architecturally pure and correct
than another, my chief interest is in seeing these capabilities being
reflected in real commercial products.

Comments welcomed, particularly from developers of commercial S/MIME client
application.

	Regards
	Dean

____________________________________________________________
Dean Adams               mobile:         +44 (0)7989 385914
Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
49 Whitehall             Office Tel:     +44 (0)20 7451 1490
London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
email: [email-masked]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: 17 September 2002 13:19
To: Dean Adams
Cc: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX

Hi Dean,

Nice to "meet" you again, not face-to-face but on the net.

> Hi,
>         Sorry for not following your rules for possible answers, but at
the moment
> I would prefer to reply with a Provisional vote for #3, since I see a real
> business need for proxy support in an S/MIME environment, (e.g. an
assistant
> signing emails and attachments on behalf of his/her boss).  This is
> something that many folks have asked if it is possible with PKI since
> current paper based practices involve some of this.

I wonder if the proxy certificate document is the right answer to your very
valid
concern.

The proxy certificate document is targeted for impersonation for access
control
but not for signature in an S/MIME context.

If your are interested in signature delegation in an S/MIME context, please
refer to
the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
2001)
where I was considering using of profile of an Attribute Certificate. The
title of
that presentation is "Signature delegation" in the slides section from the
S/MIME WG.

> The provisional nature of my vote stems from the fact that the
specification
> (as I have just read it from the PKIX site) does not mention anywhere the
> potential use of a proxy certificate in an S/MIME setting.  Furthermore,
the
> spec would seem to preclude the use of a proxy certificate in an S/MIME
> setting since the spec sates that "The subjectAltName extension MUST NOT
be
> present in a Proxy Certificate".
>
> Given my very brief reading of this spec, it is likely that I have got the
> wrong idea and that S/MIME usage can indeed be supported.  In that case I
> apologise, but would appreciate anyone explaining the situation.

For the time being I would not count your provisional vote for #3.

:-)

Regards,

Denis

>
>         Thanks
>         Dean Adams
>
> ____________________________________________________________
> Dean Adams               mobile:         +44 (0)7989 385914
> Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
> 49 Whitehall             Office Tel:     +44 (0)20 7451 1490
> London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
> email: [email-masked]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended solely
for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying, distribution
or
> any action taken or omitted to be taken in reliance on it, is prohibited
and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Steve Tuecke
> Sent: 16 September 2002 20:42
> To: [email-masked]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
> All,
>
> A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> PKIX.  Russ argued against this, which led to posing the following
> straw-poll question:
>
> >Should PKIX sanction the advancement of a proxy cert draft based on the
> >current fundamental approach?  We can argue about the details more later,
> >but the fundamental approach at issue is whether it is reasonable to use
> >end-entity public key certificates to sign proxy certificates. Possible
> >answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> suggested forming a new working group, which I would put in the #1
> category.  Denis Pinkas responded, but did not explicitly vote for one of
> these choices -- his closest statement to a vote was 'I do not have [a
> problem with using end-entity public key certificates to sign proxy
> certificates] as long as the draft is using everywhere "proxy certificate"
> and is NOT using the terminology "public key certificate"'.
>
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> apathy.  Anybody else care to weigh in on this issue?
>
> -Steve
>
> At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> >Answer: Start a new group
> >
> >PKIX was formed to do one thing and has become a standing committee that
> >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> >
> >I would much prefer to see the group split into two. Continuing PKIX
would
> >be tasked with simply moving the current RFCs through the standards track
> to
> >Draft and Standard. PKIX-EXT would be tasked with developing extensions
to
> >PKIX where necessary.
> >                 Phill

Subject: Re: What happened to the OCSPv2 draft?
To: "pgut001" <[email-masked]>
Cc: [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Tue, 17 Sep 2002 08:35:42 -0400
Sender: [email-masked]

Peter Gutman said:

"The CertID is very hard to get right for implementors (in fact one of the specific changes in 2560-bis is to try and explain it better to help people sort it out)."

How about adding an example to the text?

Frank

                      [email-masked]                                                                                                
                      nd.ac.nz (Peter          To:       [email-masked], [email-masked]                                   
                      Gutmann)                 cc:       [email-masked]                                                             
                      Sent by:                 Subject:  Re: What happened to the OCSPv2 draft?                                        
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      09/17/2002 04:45                                                                                                 
                      AM                                                                                                               

Denis Pinkas <[email-masked]> writes:

>   IssuerSerial ::= SEQUENCE {
>        issuer                   GeneralNames,
>        serialNumber             CertificateSerialNumber
>   }

Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?
That is, is there any situation where this will work and an
IssuerAndSerialNumber won't?  I can think of many situations in which (say) a
GeneralName URI + serial number (or, in general, anything which isn't the cert
issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
GeneralName in place of the issuer DN?

>ReqCert  ::= CHOICE {
>   certID            CertID,
>   certIDwithHash    [0] ESSCertID,
>   pKCert            [1] Certificate
>   }
>
>When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.

I still like the proposed v2 ID's, but I guess I can live with that if it's
what people want, except for the unusual IssuerSerial.  Can anyone explain the
semantics of the GeneralNames in there?  I can't actually see what I'd be
expected to do there, except stick in an issuer DN encoded as a GeneralName.

(I'd also allow the IssuerSerial to be optional, resource-constrained
 environments may want to send nothing more than a cert hash and offload all
 the work to the server (how much can you stuff in an SMS message :-)).

>>At this stage, given the work that has gone in OCSPv1, I don't think it is
>>worthwhile digging up this controversy again. The current option works fine
>>for OCSP as long as you aren't asking OCSP to also do path creation for you.
>>If you have already created one or more certificate chains, it isn't very
>>hard to figure out the CA's public key for any certificate in that chain.
>
>No. Precisely for the reverse argument that I have used : when you do not
>have already created one or more certificate chains, it is very hard to
>figure out the CA's public key for any certificate in that chain.

Actually I'd like to further comment on Ambarish's original comment.  The
current CertID has two problems, the first of which we've already gone
through, it doesn't identify a cert in a manner which is useful to anything
but OCSP.

The second isn't obvious from the RFC, but can be seen from discussions both
on the PKIX list and in private email: The CertID is very hard to get right
for implementors (in fact one of the specific changes in 2560-bis is to try
and explain it better to help people sort it out).  The people who have "put
in the work in OCSPv1" have got it right through guesswork, requests for help
to the list or to other implementors, or by reverse-engineering other
implementations.  There are CAs who have deployed their own software which gets
the ID wrong and who refuse to change it, citing installed software base as
the reason (I've talked to people who've had to work in this environment, it's
not fun).  Testing is almost impossible, because unless you manage to get it
exactly right you just get a response of "unknown", which may or may not mean
the ID is correct - you just have to keep guessing and trying until something
works.  This is an ongoing problem, and isn't going to get better with time,
because each new implementation has to go through this, and there will
continue to be broken implementations out there who are in a position where
they can refuse to change their code, causing great pain for anyone who has to
work with them.

Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
is left as a trivial exercise for the reader).  Everything in existence does
certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
interop/correctness checking is trivial, just click on the cert in MSIE and
look at the cert details.  issuerAndSerialNumber is similar, anything which
does S/MIME or a number of related protocols already correctly handles this,
so it's easy to find out information on and easy to check you've got it right.

Therefore I would contend that using better cert IDs will not decrease
interoperability, it will increase it, by using practical IDs which are easy
to work with and easy to get right.

Peter.

[0] OK, I haven't looked at every single PKI app in existence, but everything
    I've ever seen does it.

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Date: Tue, 17 Sep 2002 14:22:16 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Steve Hanna <[email-masked]>
CC: Steve Tuecke <[email-masked]>, [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve,

> > Should PKIX sanction the advancement of a proxy cert draft based
> > on the current fundamental approach?  We can argue about the
> > details more later, but the fundamental approach at issue is
> > whether it is reasonable to use end-entity public key
> > certificates to sign proxy certificates. Possible answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> I'll vote for:
>
> 3) Yes, as Standards Track.
>
> The proxy cert concept is a useful one. It will be increasingly
> important as long-running programs (agents or services) need to
> act on behalf of users.
>
> I would prefer an approach that gave a CA certificate to
> any user

This is not RFC 3280 compliant. :-(

> who might need to create a proxy certificate (with
> name constraints or other limitations to restrict the
> user's authority).

> This would allow the existing validation algorithm to be employed.

This is exactly what I do not think it is possible. I would not like to
"twist" the validation algorithm just for that purpose. Validating the 
proxy certificate separately, would however not be a problem.

> Revocation could be handled by an
> shared CRL issuer, using indirect CRLs to remove most overhead,
> or by a shared OCSP responder. However, I can live with the
> "current fundamental approach".

> My main concern is the lack of energy in the PKIX working
> group for this effort. If we can't muster more response
> than this, I'd say that Steve is right to take this work
> elsewhere. The PKIX working group will just slow him down.
> Individuals who are interested can join the GSI mailing lists.

The big question would still be whether that work would be RFC 3280
compliant or not.

Regards,

Denis

> Thanks,
> Steve Hanna
> Sun Microsystems, Inc.

Date: Tue, 17 Sep 2002 14:18:45 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Dean Adams <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Hi Dean,

Nice to "meet" you again, not face-to-face but on the net.

> Hi,
>         Sorry for not following your rules for possible answers, but at the moment
> I would prefer to reply with a Provisional vote for #3, since I see a real
> business need for proxy support in an S/MIME environment, (e.g. an assistant
> signing emails and attachments on behalf of his/her boss).  This is
> something that many folks have asked if it is possible with PKI since
> current paper based practices involve some of this.

I wonder if the proxy certificate document is the right answer to your very
valid
concern.

The proxy certificate document is targeted for impersonation for access
control 
but not for signature in an S/MIME context.

If your are interested in signature delegation in an S/MIME context, please
refer to
the presentation I made at the 52 nd IETF meeting (Salt Lake City, December
2001)
where I was considering using of profile of an Attribute Certificate. The
title of
that presentation is "Signature delegation" in the slides section from the
S/MIME WG.

> The provisional nature of my vote stems from the fact that the specification
> (as I have just read it from the PKIX site) does not mention anywhere the
> potential use of a proxy certificate in an S/MIME setting.  Furthermore, the
> spec would seem to preclude the use of a proxy certificate in an S/MIME
> setting since the spec sates that "The subjectAltName extension MUST NOT be
> present in a Proxy Certificate".
>
> Given my very brief reading of this spec, it is likely that I have got the
> wrong idea and that S/MIME usage can indeed be supported.  In that case I
> apologise, but would appreciate anyone explaining the situation.

For the time being I would not count your provisional vote for #3.

:-)

Regards,

Denis

>
>         Thanks
>         Dean Adams
>
> ____________________________________________________________
> Dean Adams               mobile:         +44 (0)7989 385914
> Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
> 49 Whitehall             Office Tel:     +44 (0)20 7451 1490
> London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
> email: [email-masked]    Web: http://www.trustis.com
> ____________________________________________________________
> The information in this message is confidential.  It is intended solely for
> the addressee.  Access to this message by anyone else is unauthorised.  If
> you are not the intended recipient, any disclosure, copying, distribution or
> any action taken or omitted to be taken in reliance on it, is prohibited and
> may be unlawful.
>
> Any attachments to this message have been checked for viruses, but please
> rely on your own virus checker and procedures.
>
> If you contact us by e-mail, we may store your name and address to
> facilitate communications.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Steve Tuecke
> Sent: 16 September 2002 20:42
> To: [email-masked]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
> All,
>
> A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
> PKIX.  Russ argued against this, which led to posing the following
> straw-poll question:
>
> >Should PKIX sanction the advancement of a proxy cert draft based on the
> >current fundamental approach?  We can argue about the details more later,
> >but the fundamental approach at issue is whether it is reasonable to use
> >end-entity public key certificates to sign proxy certificates. Possible
> >answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
> suggested forming a new working group, which I would put in the #1
> category.  Denis Pinkas responded, but did not explicitly vote for one of
> these choices -- his closest statement to a vote was 'I do not have [a
> problem with using end-entity public key certificates to sign proxy
> certificates] as long as the draft is using everywhere "proxy certificate"
> and is NOT using the terminology "public key certificate"'.
>
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> apathy.  Anybody else care to weigh in on this issue?
>
> -Steve
>
> At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> >Answer: Start a new group
> >
> >PKIX was formed to do one thing and has become a standing committee that
> >will do anything, provided it is in ASN.1 syntax. That is a bad thing.
> >
> >I would much prefer to see the group split into two. Continuing PKIX would
> >be tasked with simply moving the current RFCs through the standards track
> to
> >Draft and Standard. PKIX-EXT would be tasked with developing extensions to
> >PKIX where necessary.
> >
> >
> >                 Phill

Date: Tue, 17 Sep 2002 14:17:00 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter,

> Denis Pinkas <[email-masked]> writes:
>
> >   IssuerSerial ::= SEQUENCE {
> >        issuer                   GeneralNames,
> >        serialNumber             CertificateSerialNumber
> >   }
>
> Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?

This is the one defined in RFC 2634, so I would not qualify it as a
"nonstandard variation".

This structure is useful in some cases. See below.

> I can think of many situations in which (say) a
> GeneralName URI + serial number (or, in general, anything which isn't the cert
> issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
> GeneralName in place of the issuer DN?
>
> >ReqCert  ::= CHOICE {
> >   certID            CertID,
> >   certIDwithHash    [0] ESSCertID,
> >   pKCert            [1] Certificate
> >   }
> >
> >When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.
>
> I still like the proposed v2 ID's, but I guess I can live with that if it's
> what people want, except for the unusual IssuerSerial.  Can anyone explain the
> semantics of the GeneralNames in there?  I can't actually see what I'd be
> expected to do there, except stick in an issuer DN encoded as a GeneralName.

GeneralNames is defined in X.509 as:

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

> That is, is there any situation where this will work and an
> IssuerAndSerialNumber won't?

IssuerAndSerialNumber is defined in RFC 2630 as:

      IssuerAndSerialNumber ::= SEQUENCE {
        issuer          Name,
        serialNumber    CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

Paul Hoffman, the editor, would certainly be in a better position to
respond. Since RFC 2634 was created after RFC 2630 there must be a good
reason.  

Let me try to explain. Let us assume that the DN of the CA only contains 
CN=OpenCA.

Let us assume that a certificate for OpenCA is issued by a CA with a DN 
that only contains CN=LawyersCA

Let us assume that another certificate for OpenCA is issued by a CA with 
a DN that only contains CN=NotariesCA
  
You got it: to make sure that you are referencing the right certificate, 
a sequence of DNs is needed, so that the names of the upper CAs can be
included.

The hash can tell you that you got a wrong certificate, but will not help
you to look for the good one.

I would agree that it is likely to be an exceptional case, but this gives
some flexibility.

Denis

> (I'd also allow the IssuerSerial to be optional, resource-constrained
>  environments may want to send nothing more than a cert hash and offload all
>  the work to the server (how much can you stuff in an SMS message :-)).
 
> >>At this stage, given the work that has gone in OCSPv1, I don't think it is
> >>worthwhile digging up this controversy again. The current option works fine
> >>for OCSP as long as you aren't asking OCSP to also do path creation for you.
> >>If you have already created one or more certificate chains, it isn't very
> >>hard to figure out the CA's public key for any certificate in that chain.

> >No. Precisely for the reverse argument that I have used : when you do not
> >have already created one or more certificate chains, it is very hard to
> >figure out the CA's public key for any certificate in that chain.

> Actually I'd like to further comment on Ambarish's original comment.  The
> current CertID has two problems, the first of which we've already gone
> through, it doesn't identify a cert in a manner which is useful to anything
> but OCSP.
>
> The second isn't obvious from the RFC, but can be seen from discussions both
> on the PKIX list and in private email: The CertID is very hard to get right
> for implementors (in fact one of the specific changes in 2560-bis is to try
> and explain it better to help people sort it out).  The people who have "put
> in the work in OCSPv1" have got it right through guesswork, requests for help
> to the list or to other implementors, or by reverse-engineering other
> implementations.  There are CAs who have deployed their own software which gets
> the ID wrong and who refuse to change it, citing installed software base as
> the reason (I've talked to people who've had to work in this environment, it's
> not fun).  Testing is almost impossible, because unless you manage to get it
> exactly right you just get a response of "unknown", which may or may not mean
> the ID is correct - you just have to keep guessing and trying until something
> works.  This is an ongoing problem, and isn't going to get better with time,
> because each new implementation has to go through this, and there will
> continue to be broken implementations out there who are in a position where
> they can refuse to change their code, causing great pain for anyone who has to
> work with them.
>
> Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
> is left as a trivial exercise for the reader).  Everything in existence does
> certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
> interop/correctness checking is trivial, just click on the cert in MSIE and
> look at the cert details.  issuerAndSerialNumber is similar, anything which
> does S/MIME or a number of related protocols already correctly handles this,
> so it's easy to find out information on and easy to check you've got it right.
>
> Therefore I would contend that using better cert IDs will not decrease
> interoperability, it will increase it, by using practical IDs which are easy
> to work with and easy to get right.
>
> Peter.
>
> [0] OK, I haven't looked at every single PKI app in existence, but everything
>     I've ever seen does it.

From: "Dean Adams" <[email-masked]>
To: <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Tue, 17 Sep 2002 12:38:44 +0100
Importance: Normal
Sender: [email-masked]

Hi,
	Sorry for not following your rules for possible answers, but at the moment
I would prefer to reply with a Provisional vote for #3, since I see a real
business need for proxy support in an S/MIME environment, (e.g. an assistant
signing emails and attachments on behalf of his/her boss).  This is
something that many folks have asked if it is possible with PKI since
current paper based practices involve some of this.

The provisional nature of my vote stems from the fact that the specification
(as I have just read it from the PKIX site) does not mention anywhere the
potential use of a proxy certificate in an S/MIME setting.  Furthermore, the
spec would seem to preclude the use of a proxy certificate in an S/MIME
setting since the spec sates that "The subjectAltName extension MUST NOT be
present in a Proxy Certificate".

Given my very brief reading of this spec, it is likely that I have got the
wrong idea and that S/MIME usage can indeed be supported.  In that case I
apologise, but would appreciate anyone explaining the situation.

	Thanks
	Dean Adams

____________________________________________________________
Dean Adams               mobile:         +44 (0)7989 385914
Trustis Limited          Direct Tel/Fax: +44 (0)1252 734320
49 Whitehall             Office Tel:     +44 (0)20 7451 1490
London SW1A 2BX          Office Fax:     +44 (0)20 7484 7961
email: [email-masked]    Web: http://www.trustis.com
____________________________________________________________
The information in this message is confidential.  It is intended solely for
the addressee.  Access to this message by anyone else is unauthorised.  If
you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.

Any attachments to this message have been checked for viruses, but please
rely on your own virus checker and procedures.

If you contact us by e-mail, we may store your name and address to
facilitate communications.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Steve Tuecke
Sent: 16 September 2002 20:42
To: [email-masked]
Cc: Steve Tuecke
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX

All,

A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from
PKIX.  Russ argued against this, which led to posing the following
straw-poll question:

>Should PKIX sanction the advancement of a proxy cert draft based on the
>current fundamental approach?  We can argue about the details more later,
>but the fundamental approach at issue is whether it is reasonable to use
>end-entity public key certificates to sign proxy certificates. Possible
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker
suggested forming a new working group, which I would put in the #1
category.  Denis Pinkas responded, but did not explicitly vote for one of
these choices -- his closest statement to a vote was 'I do not have [a
problem with using end-entity public key certificates to sign proxy
certificates] as long as the draft is using everywhere "proxy certificate"
and is NOT using the terminology "public key certificate"'.

So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
apathy.  Anybody else care to weigh in on this issue?

-Steve

At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
>Answer: Start a new group
>
>PKIX was formed to do one thing and has become a standing committee that
>will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>
>I would much prefer to see the group split into two. Continuing PKIX would
>be tasked with simply moving the current RFCs through the standards track
to
>Draft and Standard. PKIX-EXT would be tasked with developing extensions to
>PKIX where necessary.
>
>
>                 Phill

Date: Tue, 17 Sep 2002 06:53:09 -0400
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: [email-masked]
CC: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Steven,

An interesting observation on how the text in the
DER standard can be interpreted. But really, any
TeletextString users have much bigger problems.

Phil

Steven Legg wrote:

> 
>>Of course, there already is a more efficient encoding for XML
>>markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
>>shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
>>and that exactly the same abstract values can be encoded in 
>>50+ bytes in
>>DER. The obvious conclusion is that for every canonical DER 
>>value there
>>is a canonical XER encoding that yields an XMl markup 
>>representation of 
>>that same value.
>>
> 
> It is important to note that it is a many-to-one mapping. For each
> canonical XER encoding there are, in general, many DER encodings.
> This comes about because the DER/BER encoding of TeletexString provides
> many ways to represent the same string of abstract characters, and
> all these alternatives have exactly the same representation in XER.
> 
> Consequently, taking a DER encoding, re-encoding in XER, and then
> re-encoding in DER is not guaranteed to reproduce exactly the original
> DER encoding. However, taking a canonical XER encoding, re-encoding in DER,
> and then re-encoding in canonical XER will reproduce the original
> canonical XER encoding.
> 
> Regards,
> Steven
> 
> 
> 

Date: Tue, 17 Sep 2002 12:48:36 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter Gutmann wrote:
> Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
> is left as a trivial exercise for the reader).  Everything in existence does
> certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
> interop/correctness checking is trivial, just click on the cert in MSIE and
> look at the cert details.

Well, one of the problems with current fingerprint implementations is 
that some implementations use MD5 and some use SHA-1...

But this can be easily fixed by making use of SHA-1 mandatory.

> Therefore I would contend that using better cert IDs will not decrease
> interoperability, it will increase it, by using practical IDs which are easy
> to work with and easy to get right.

+1

Ciao, Michael.

Date: Tue, 17 Sep 2002 20:45:49 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>   IssuerSerial ::= SEQUENCE {
>        issuer                   GeneralNames,
>        serialNumber             CertificateSerialNumber
>   }

Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?
That is, is there any situation where this will work and an
IssuerAndSerialNumber won't?  I can think of many situations in which (say) a
GeneralName URI + serial number (or, in general, anything which isn't the cert
issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
GeneralName in place of the issuer DN?

>ReqCert  ::= CHOICE {
>   certID            CertID,
>   certIDwithHash    [0] ESSCertID,
>   pKCert            [1] Certificate
>   }
>
>When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.

I still like the proposed v2 ID's, but I guess I can live with that if it's
what people want, except for the unusual IssuerSerial.  Can anyone explain the
semantics of the GeneralNames in there?  I can't actually see what I'd be
expected to do there, except stick in an issuer DN encoded as a GeneralName.

(I'd also allow the IssuerSerial to be optional, resource-constrained
 environments may want to send nothing more than a cert hash and offload all
 the work to the server (how much can you stuff in an SMS message :-)).

>>At this stage, given the work that has gone in OCSPv1, I don't think it is
>>worthwhile digging up this controversy again. The current option works fine
>>for OCSP as long as you aren't asking OCSP to also do path creation for you.
>>If you have already created one or more certificate chains, it isn't very
>>hard to figure out the CA's public key for any certificate in that chain.
>
>No. Precisely for the reverse argument that I have used : when you do not
>have already created one or more certificate chains, it is very hard to
>figure out the CA's public key for any certificate in that chain.

Actually I'd like to further comment on Ambarish's original comment.  The
current CertID has two problems, the first of which we've already gone
through, it doesn't identify a cert in a manner which is useful to anything
but OCSP.

The second isn't obvious from the RFC, but can be seen from discussions both
on the PKIX list and in private email: The CertID is very hard to get right
for implementors (in fact one of the specific changes in 2560-bis is to try
and explain it better to help people sort it out).  The people who have "put
in the work in OCSPv1" have got it right through guesswork, requests for help
to the list or to other implementors, or by reverse-engineering other
implementations.  There are CAs who have deployed their own software which gets
the ID wrong and who refuse to change it, citing installed software base as
the reason (I've talked to people who've had to work in this environment, it's
not fun).  Testing is almost impossible, because unless you manage to get it
exactly right you just get a response of "unknown", which may or may not mean
the ID is correct - you just have to keep guessing and trying until something
works.  This is an ongoing problem, and isn't going to get better with time,
because each new implementation has to go through this, and there will
continue to be broken implementations out there who are in a position where
they can refuse to change their code, causing great pain for anyone who has to
work with them.

Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
is left as a trivial exercise for the reader).  Everything in existence does
certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
interop/correctness checking is trivial, just click on the cert in MSIE and
look at the cert details.  issuerAndSerialNumber is similar, anything which
does S/MIME or a number of related protocols already correctly handles this,
so it's easy to find out information on and easy to check you've got it right.

Therefore I would contend that using better cert IDs will not decrease
interoperability, it will increase it, by using practical IDs which are easy
to work with and easy to get right.

Peter.

[0] OK, I haven't looked at every single PKI app in existence, but everything
    I've ever seen does it.

Date: Tue, 17 Sep 2002 09:40:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Ambarish Malpani <[email-masked]>
CC: David Hopwood <[email-masked]>, [email-masked]
Subject: RFC2560bis
Sender: [email-masked]

Ambarish,

> Hi David,
>     That draft was put out long before the discussion about the
> value of the nonce extension discussion came up.
>
> I was planning to make that change when we got the author's 24
> hour call.

Would you indicate exactly what is the intended change ?

Regards,

Denis

>
> Regards,
> Ambarish
>
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [email-masked]
> http://www.malpani.biz
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of David Hopwood
> > Sent: Saturday, September 14, 2002 6:13 PM
> > To: [email-masked]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Denis Pinkas wrote:
> > > I do not care about OCSP v2: some documents die.
> > >
> > > However, I care with OCSP(v1)bis. The Yokohama meeting report states:
> > >
> > > "Roadmap, OCSP(v1)bis and PI documents in IESG queue."
> > >
> > > The document is available at:
> > http://www.imc.org/draft-ietf-pkix-rfc2560bis
> >
> > I notice that this draft does not clarify the syntax of the nonce
> > extension,
> > as discussed on this list in May-June. (The conclusion was that
> > clients should
> > use an OCTET STRING as the encapsulated type.)
> >
> > - --
> > David Hopwood <[email-masked]>
> >
> > Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> > RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
> > Nothing in this message is intended to be legally binding. If I revoke a
> > public key but refuse to specify why, it is because the private
> > key has been
> > seized under the Regulation of Investigatory Powers Act; see
> www.fipr.org/rip
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBPYPeYzkCAxeYt5gVAQFoEgf+MS2l0tGK6R+yQQwxYKK9Rs7U1ZxxuFWC
> TwozeeIB3JQyBul5dmgTL4vKMgOCqvf/4Yif9E92WRlyWTVFauy5YTQhJwCjJM2v
> BtSvVAUBE2rHYi5wEGeu7bRSngJHwaPEF2M6+2fmdZ1MCLmdt9F+Nn95BWTu2peI
> u1pZx8vn/IqHJ674I+Z9KmG7E0eqBbjjf3IP9j07h2LrpW/eOy9IyESv0zP2xSxn
> pOmW4SijpRJeF2YVWVaryOz9hZzl93nyffZlBTE+qMseayuwah13tca1jzYFMY+j
> zaf2oW7as38jQ1zNgl/BOoxOCGDf42IbfB3Wi2pNw9i3rDWQahbW4g==
> =BbyB
> -----END PGP SIGNATURE-----

Date: Tue, 17 Sep 2002 09:37:13 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Hallam-Baker, Phillip" <[email-masked]>, "[email-masked]'" <[email-masked]>
CC: [email-masked]
Subject: XML versus XER/ASN.1 (was Re: What happened to the OCSPv2 draft?)
Sender: [email-masked]

Phill and Phil,

I would appreciate that you change the subject of the e-mails 
when you change topic.

Regards,

Denis

> Has any party commercial or non-comercial endorsed the
> proposed 'standard' and committed to supporting it?
>
> It is one thing to get a bunch of people to agree to
> a proposal, quite another to persuade an industry to
> deploy.
>
> I fail to see the value of an XML expression of deployed
> X.509 semantics. I fail to see the value of an ASN.1
> encoding to rival deployed XML specifications.
>
>                 Phill
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, September 13, 2002 4:19 PM
> > To: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: What happened to the OCSPv2 draft?
> >
> >
> > Of course, there already is a more efficient encoding for XML
> > markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> > shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> > and that exactly the same abstract values can be encoded in
> > 50+ bytes in
> > DER. The obvious conclusion is that for every canonical DER
> > value there
> > is a canonical XER encoding that yields an XMl markup
> > representation of
> > that same value. Clearly messages can be stored and transferrd in DER
> >  (which is not a particularly compact ASN.1 encoding, but
> > which enjoys
> >  tools are cheap  and readily available) and exploded into
> > XML markup in
> > resource rich environments.
> >
> > This is the thrust of the OASIS XML Common Biometric Format, the 2002
> > revision of the X9.84 biometric information management and security ,
> > the X9.96 XML Cryptographic Message Syntax, and the  X9.95
> > Trusted Time
> > Stamp standards. It is also the core of the NWI proposal in
> > ISO TC68/SC2
> > based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> > compressed domain certificate standard that moved forward in
> > ISO this week.
> > If passed, this will result in a DER encoded certificate that is much
> > smaller
> > than the X.509 certificate format it is based on, and a
> > completely XML
> > certificate as well. The possibilities this will create to
> > stir the pot
> > will be
> >  interesting.
> >
> > The idea of this approach is compelling for several reasons.
> > It provides a
> > migration path into the XML space for ASN.1 defined specifications, it
> > allows
> > systems to be built  like my Biolojava tool kit that provide
> > support  for
> > both XML
> > aware and ASN.1 aware applications, and it provides
> > compression for XML
> > values.
> >
> > But the really sweet  fallout of this is the simplicity of the XML
> > signature
> > processing. It turns out to be almost equivalent  to the processing
> > description used currently for DER in the IETF SMIME standard.
> > Anyone that can do SignedData using DER can, without nearly a
> > thought, do the same with XML markup and leverage the browser.
> >
> > And there are tools like mine emerging to support  these concepts, and
> > standards that will use them.
> >
> > Phil

Date: Tue, 17 Sep 2002 09:35:50 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Jeff Jacoby <[email-masked]>
CC: "[email-masked] '" <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Jeff,

> Denis Pinkas wrote:
> >
> > Florian,
> 
> [snip]
> 
> > > Thus we should add an extension regarding the time of revocation
> > > checking - to allow the validation protocol to use OCSP while
> > fulfilling
> > > the DPV-DPD requirements:
> >
> > > "The client can request that the server determine the certificate
> > > validity at a time other than the current time. The DPV server MUST
> > > obtain revocation status information for the validation time in the
> > > client request." - DPV-DPD requirements document
> >
> > I do not think that adding a parameter in the request to specify a time
> > in the past (which is I guess what you are proposing) is necessary.
> 
> 
> I've never quite understood the utility of the archive cutoff value.
> 
> I find the "contribute to a proof" arguement, in section 4.4.4, rather
> vague. So I know the responder archives data for the last 7 years.

It is true that the text is not very explicit. The intent was not an archive
for 7 years.

> So what?
> 
> If I can't query the responder to see if a cert was revoked 6.5 years
> ago how does knowing the cutoff was 7 year ago really contribute to a proof
> 
> I think having a request parameter specify a time in the past better
> enables a client to take advantage of the cutoff information.  I can see
> it's not strictly necessary, but it would be really nice to have.
> 
> > A signature has to be validated close to the time it was made and thus
> > the revocation status information has to be captured close to that time.
> 
> I would argue this is too limiting.  If revocation information is
> archived then we shouldn't restrict an RP from getting that information
> no matter when the signature was created.
> 
> Here's an example (somewhat contrived):
> 
>   - Executive of company E signs some financial documents/contracts.
> 
>   - After a short time the certificate is revoked (say, the Executive
>     left the company).
> 
>   - A year later company E is under investigation for shady financial
>     dealings, which may include the above signed document.
> 
> Isn't it reasonable for the investigators to determine--a year after the
> signature was created--if the cert was revoked then?

A signature has to be checked as soon as possible. The problem is that you
can receive a signed e-mail while you are in vacations. I do not assume that
anyone is taking 7 years vacations. :-)

Let us assume that archive cutoff period to be set to a maximum of six
weaks. This means that when you come back for your 4 weeks vacations 
(2 weeks in your country), you can still check the revocation state of 
the certificate, even if the certificate was used the very last day of 
its validity period.
 
Denis
 
> > We already have the archive cutoff in case an OCSP responder chooses
> > to retain revocation information beyond a certificate's expiration.
> 
> My apologies if I've mis-understood some of these issues.
> 
> Jeff
> --
> Jeff Jacoby, Principal Programmer
> RSA Security Inc., SMDC                    [email-masked]
> 2955 Campus Dr., Ste. 400                  (650) 295-7569
> San Mateo, CA  94403

Date: Tue, 17 Sep 2002 09:33:31 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter,

> Denis Pinkas <[email-masked]> writes:
> 
> >OCSP v2 should NOT expand its possibilities beyond certificate revocation
> >checking and certainly should NOT try to expand its capabilities to cover
> >certificate validation.
> >
> >To be more precise, I do not care about the expired OCSP v2 draft, but I
> >care about fixing RFC 2560, while sticking to its original functionality:
> >individual certificate revocation information status check.
> >
> >Having said that, we should correct the major problem that exists in
> >RFC 2560, which is how the certificate can be defined.
> >
> >[...]
> 
> I agree with absolutely everything Denis has said.

Fine.
 
> [Pause.  Rereads post two more times]
> 
> Ah, I finally found something to disagree with: The tag for the OCTET STRING
> is redundant :-).
> 
> All OCSP really needs is a more usable way to identify certs, and the CRL
> locator would be useful too.  

Yes.

> Both of these are trivial additions to OCSP  which could be easily added 
> to 2560-bis, and don't require any v2, which was adding all sorts of other 
> stuff to the extent where it was almost a different protocol.  

Yes.

> If there's total opposition to making this tiny change to 2560-
> bis, and since no-one has spoken out for the current v2 draft, I'll do the new
> v2 draft myself (or do you want to do it Denis?).  It's only going to be a
> page or so of text by the looks of it.

Before doing it, it would be nice to agree on the additions to OCSP allowing 
more usable way to identify certs.

See my detailed response to Ambarish on that topic.

Then if we all agree, I would rather prefer that we first propose the role
of editor to one of the original authors. If no one volonteers, then your
proposal of being the lead editor should certainly be considered.

Regards,

Denis 

> Peter.

Date: Tue, 17 Sep 2002 09:31:48 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Ambarish,

> Hi Denis,

>     To make this easier to read, I will skip the part we agree on.

Fine.
 
> Here is the controversial topic: Do we need multiple ways of
> identifying a certificate. My contention is no. We need to
> decide on one and use that.
> 
> I see 2 reasonable options:
> 1. The current cert serial number and issuer name/key hash
> 2. The full certificate

The very first question is whether the current way is reasonable: 
i.e. cert serial number + issuer name hash + issuer key hash.

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

I do not think it is.

It does not allow optimization of path checking. I would like a RP to be
able to send an OCSP request with only the certificate at hand. 

Today a path must first be constructed because the certificate only does not
allow to know the hash of the issuer's public key. 

Then, in order to make sure that the OCSP response is coming from the right
responder (in the case where the CA has designated its OCSP responders by
including id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificates), the RP has to check
that the OCSP name included in the certificate matches the Name included in
the ResponderID: 

   ResponderID ::= CHOICE {
      byName               [1] Name,
      byKey                [2] KeyHash }

Alternatively, the RP has to check the KeyHash and for doing this.

In any case, the RP needs the OCSP certificate.
  
The certs field from the BasicOCSPResponse is only optional, and I would
make it mandatory  in the case where the CA has designated its OCSP
responders by including id-kp-OCSPSigning ... It would be nice for that
field to contain not only the OCSP responder certificate, but also the
certification chain. I already see Phill struggling to get that protocol
packaging into a single ethernet frame. Thus it would be nice to be able to
request the full chain, only when needed. This could be done using
requestExtensions.

In this way, the RP could validate the signature from the OCSP responder,
but much more important, when the OCSP request is not forwarded to another 
OCSP server, would get "for free" the certification path the verify the 
certificate that was under the original query, and could even get rid of 
using LDAP.

When the request is forwarded to another OCSP server, certs could include, 
upon request, another certification chain for the certificate under query 
up to a root key. This could be done using singleRequestExtensions.

Now let us come to the conclusion:

Option 1 does not fill the case mentioned above.
Option 2 of course does fill it.

What about an option 3 ?

pkix-rfc2560bis-01.txt defines Request as:

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

The expired OCSPv2 draft was proposing to define: 

Request         ::=     SEQUENCE {
   reqCert                     ReqCert,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

with:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}
     
CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

In order to identify unambiguously a certificate, RFC 2634 is using the
right syntax:

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

with:

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

This is a very compact form that Phill should like, despite it is in ASN.1. 
:-)

So let us come to my proposal for identifying a certificate:

Request         ::=     SEQUENCE {
   reqCert                     ReqCert,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

with:

ReqCert  ::= CHOICE {
   certID            CertID,
   certIDwithHash    [0] ESSCertID,
   pKCert            [1] Certificate
   }

When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is
mandatory.
 
> I know in the past folks from VeriSign hated the second option. I
> believe this was because their certs were pretty large (with
> statements about limitations of liability, etc.).
> 
> At this stage, given the work that has gone in OCSPv1, I don't
> think it is worthwhile digging up this controversy again. The
> current option works fine for OCSP as long as you aren't asking
> OCSP to also do path creation for you. If you have already
> created one or more certificate chains, it isn't very hard
> to figure out the CA's public key for any certificate in that
> chain.
 
> Makes sense?

No. Precisely for the reverse argument that I have used : when you do not
have already created one or more certificate chains, it is very hard to
figure out the CA's public key for any certificate in that chain.

Regards,

Denis

> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [email-masked]
> http://www.malpani.biz
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [email-masked]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > Oops - too many messages just while I am transitioning....
> > >
> > > Steve, if I remember correctly, what we agreed on was that
> > > badly designed extensions can screw up a perfectly good
> > > protocol. So can badly designed implementations....
> > >
> > > Denis, I like the suggestion about allowing a client to include
> > > the CRLDP extension in requests.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > I don't like the suggestion of
> > > providing multiple means of identifying certificates - it
> > > adds more interoperability problems and doesn't add much to
> > > the protocol - assuming that we agree that OCSP was meant to
> > > provide the status of a certificate.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    CertificateSerialNumber  ::=  INTEGER
> >
> > You cannot directly know the DN of the CA. You have to use a list of known
> > CAs and compute the hash over each of them to perform the match. This is a
> > severe limitation.
> >
> > > For the former, all we need to do is define the extension. That
> > > really doesn't need work on a OCSPv2 at all.
> >
> > I agree that, for defining an extension for handling a CRLDP extension in
> > requests, we do not need to define a v2 version, since it would be
> > applicable to v1.
> >
> > Regards,
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; [email-masked] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > Steve,
> > > >
> > > > You said:
> > > >
> > > > "Ambarish later recalled that I warned him about the problems that
> > > > extensions to OCSP might engender, and he agreed that they had come
> > > > to cause problems."
> > > >
> > > > I do agree we you.
> > > >
> > > > To come back to technical issues, the expired OCSP v2 draft
> > was expanding
> > > > its possibilities beyond certificate revocation checking, whereas some
> > > > fixing on the deficiencies of RFC 2560 would have been needed, in
> > > > particular, as pointed by Peter, more ways to select the
> > certificate to be
> > > > checked.
> > > >
> > > > OCSP v2 should NOT expand its possibilities beyond
> > certificate revocation
> > > > checking and certainly should NOT try to expand its
> > capabilities to cover
> > > > certificate validation.
> > > >
> > > > To be more precise, I do not care about the expired OCSP v2
> > draft, but I
> > > > care about fixing RFC 2560, while sticking to its original
> > functionality:
> > > > individual certificate revocation information status check.
> > > >
> > > > Having said that, we should correct the major problem that exists in
> > > > RFC 2560, which is how the certificate can be defined.
> > > >
> > > > The proposal in the last draft
> > (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > > >
> > > > ReqCert  ::= CHOICE {
> > > >    certID            CertID,
> > > >    issuerSerial      [0] IssuerandSerialNumber,
> > > >    pKCert            [1] Certificate,
> > > >    name              [2] GeneralName,
> > > >    certHash          [3] OCTET STRING}
> > > >
> > > > CertID          ::=     SEQUENCE {
> > > >    hashAlgorithm       AlgorithmIdentifier,
> > > >    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> > > >    issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
> > > >    serialNumber        CertificateSerialNumber }
> > > >
> > > > In addition, RFC 2560 includes a serviceLocator request
> > extension, which
> > > > is nice when an OCSP service is supported in the background.
> > However, it
> > > > does not include any extension when a CRL is supported in the
> > background.
> > > > This means that the OCSP server cannot know in general where
> > the CRL to be
> > > > used is located.
> > > >
> > > > :-(
> > > >
> > > > One way would be to send the whole certificate (this is NOT
> > possible with
> > > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > > responder,
> > > > but another possibility would be to use an extension where the CDP
> > > > information present in the certificate would copied and pasted in that
> > > > extension. Then, using issuerSerial, the OCSP responder can
> > > > perform the CRL
> > > > check and to transform it into an OCSP response.
> > > >
> > > > Such extension would look like:
> > > >
> > > > ==================================================================
> > > > =========
> > > > 8.X     CRL Locator
> > > >
> > > > An OCSP server may be operated in a mode whereby the server receives a
> > > > request and fetches the CRL which authoritative for the identified
> > > > certificate. The crlLocator request extension is defined for this
> > > > purpose.
> > > > This extension is included as one of the singleRequestExtensions in
> > > > requests.
> > > >
> > > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
> > > >
> > > >    CrlLocator ::= CRLDistributionPoints
> > > >
> > > > The value for this field is obtained from the corresponding
> > field in the
> > > > subject certificate.
> > > >
> > > > ==================================================================
> > > > =========
> > > >
> > > > So my proposal would be to issue a new OCSP v2 draft, only
> > > > including these
> > > > two changes. Anything else I forgot ?
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> >

Date: Tue, 17 Sep 2002 15:53:59 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Phil Griffin <[email-masked]> writes:

>Hoping to foment a groundswell of activity, I agree with Russ on this.

Hoping to foment a nice stress-relieving flamewar, I'll agree with Phil that
since PKIX will standardise anything with an ASN.1 syntax, we may as well do
this one as well.

Peter >:-).

From: "Ambarish Malpani" <[email-masked]>
To: "David Hopwood" <[email-masked]>, <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Mon, 16 Sep 2002 19:50:45 -0700
Importance: Normal
Sender: [email-masked]

Hi David,
    That draft was put out long before the discussion about the
value of the nonce extension discussion came up.

I was planning to make that change when we got the author's 24
hour call.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Hopwood
> Sent: Saturday, September 14, 2002 6:13 PM
> To: [email-masked]
> Subject: Re: What happened to the OCSPv2 draft?
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Denis Pinkas wrote:
> > I do not care about OCSP v2: some documents die.
> >
> > However, I care with OCSP(v1)bis. The Yokohama meeting report states:
> >
> > "Roadmap, OCSP(v1)bis and PI documents in IESG queue."
> >
> > The document is available at:
> http://www.imc.org/draft-ietf-pkix-rfc2560bis
>
> I notice that this draft does not clarify the syntax of the nonce
> extension,
> as discussed on this list in May-June. (The conclusion was that
> clients should
> use an OCTET STRING as the encapsulated type.)
>
> - --
> David Hopwood <[email-masked]>
>
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private
> key has been
> seized under the Regulation of Investigatory Powers Act; see
www.fipr.org/rip

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Tue, 17 Sep 2002 11:36:03 +1100
Importance: Normal
Sender: [email-masked]

> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value.

It is important to note that it is a many-to-one mapping. For each
canonical XER encoding there are, in general, many DER encodings.
This comes about because the DER/BER encoding of TeletexString provides
many ways to represent the same string of abstract characters, and
all these alternatives have exactly the same representation in XER.

Consequently, taking a DER encoding, re-encoding in XER, and then
re-encoding in DER is not guaranteed to reproduce exactly the original
DER encoding. However, taking a canonical XER encoding, re-encoding in DER,
and then re-encoding in canonical XER will reproduce the original
canonical XER encoding.

Regards,
Steven

Date: Tue, 17 Sep 2002 00:43:03 +0100
From: Dr S N Henson <[email-masked]>
To: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

I'll vote for #3 too.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

From: "Michael Myers" <[email-masked]>
To: "Steve Tuecke" <[email-masked]>, <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Mon, 16 Sep 2002 14:17:30 -0700
Importance: Normal
Sender: [email-masked]

Steve,

I think #3 is a good way to address this recurring class of
unmet needs.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Steve Tuecke
> Sent: Monday, September 16, 2002 12:42 PM
> To: [email-masked]
> Cc: Steve Tuecke
> Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
>
>
>
> All,
>
> A couple weeks ago, I proposed withdrawal of the
> Proxy Cert Profile from
> PKIX.  Russ argued against this, which led to posing
> the following
> straw-poll question:
>
> >Should PKIX sanction the advancement of a proxy cert
> draft based on the
> >current fundamental approach?  We can argue about
> the details more later,
> >but the fundamental approach at issue is whether it
> is reasonable to use
> >end-entity public key certificates to sign proxy
> certificates. Possible
> >answers are:
> >   1) No.
> >   2) Yes, but only as Informational Track.
> >   3) Yes, as Standards Track.
>
> There were 3 responses.  Russ Housley voted #3.
> Phill Hallam-Baker
> suggested forming a new working group, which I would
> put in the #1
> category.  Denis Pinkas responded, but did not
> explicitly vote for one of
> these choices -- his closest statement to a vote was
> 'I do not have [a
> problem with using end-entity public key certificates
> to sign proxy
> certificates] as long as the draft is using
> everywhere "proxy certificate"
> and is NOT using the terminology "public key certificate"'.
>
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of
> apathy.  Anybody else care to weigh in on this issue?
>
> -Steve

Date: Mon, 16 Sep 2002 17:07:57 -0400
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: Steve Tuecke <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Hoping to foment a groundswell of activity,
I agree with Russ on this.

Phil

Steve Tuecke wrote:

> 
> All,
> 
> A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from 
> PKIX.  Russ argued against this, which led to posing the following 
> straw-poll question:
> 
>> Should PKIX sanction the advancement of a proxy cert draft based on 
>> the current fundamental approach?  We can argue about the details more 
>> later, but the fundamental approach at issue is whether it is 
>> reasonable to use end-entity public key certificates to sign proxy 
>> certificates. Possible answers are:
>>   1) No.
>>   2) Yes, but only as Informational Track.
>>   3) Yes, as Standards Track.
> 
> 
> There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker 
> suggested forming a new working group, which I would put in the #1 
> category.  Denis Pinkas responded, but did not explicitly vote for one 
> of these choices -- his closest statement to a vote was 'I do not have 
> [a problem with using end-entity public key certificates to sign proxy 
> certificates] as long as the draft is using everywhere "proxy 
> certificate" and is NOT using the terminology "public key certificate"'.
> 
> So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of apathy.  
> Anybody else care to weigh in on this issue?
> 
> -Steve
> 
> At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
> 
>> Answer: Start a new group
>>
>> PKIX was formed to do one thing and has become a standing committee that
>> will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>>
>> I would much prefer to see the group split into two. Continuing PKIX 
>> would
>> be tasked with simply moving the current RFCs through the standards 
>> track to
>> Draft and Standard. PKIX-EXT would be tasked with developing 
>> extensions to
>> PKIX where necessary.
>>
>>
>>                 Phill
> 
> 
> 

Date: Mon, 16 Sep 2002 17:01:04 -0400
From: Steve Hanna <[email-masked]>
To: Steve Tuecke <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

> Should PKIX sanction the advancement of a proxy cert draft based
> on the current fundamental approach?  We can argue about the
> details more later, but the fundamental approach at issue is
> whether it is reasonable to use end-entity public key
> certificates to sign proxy certificates. Possible answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

I'll vote for:

3) Yes, as Standards Track.

The proxy cert concept is a useful one. It will be increasingly
important as long-running programs (agents or services) need to
act on behalf of users.

I would prefer an approach that gave a CA certificate to
any user who might need to create a proxy certificate (with
name constraints or other limitations to restrict the
user's authority). This would allow the existing validation
algorithm to be employed. Revocation could be handled by an
shared CRL issuer, using indirect CRLs to remove most overhead,
or by a shared OCSP responder. However, I can live with the
"current fundamental approach".

My main concern is the lack of energy in the PKIX working
group for this effort. If we can't muster more response
than this, I'd say that Steve is right to take this work
elsewhere. The PKIX working group will just slow him down.
Individuals who are interested can join the GSI mailing lists.

Thanks,

Steve Hanna
Sun Microsystems, Inc.

Date: Mon, 16 Sep 2002 16:01:46 -0400
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: "Hallam-Baker, Phillip" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Phillip,

Hallam-Baker, Phillip wrote:

> 
>>>I fail to see the value of an XML expression of deployed
>>>X.509 semantics. I fail to see the value of an ASN.1
>>>encoding to rival deployed XML specifications.
>>>
> 
>>I see much value in X.509 semantics, regardless of the
>>form of their expression. XML markup is just another
>>encoding rule for ASN.1 values.
>>
> 
> I still fail to see the advantage to an incompatible syntax
> for an existing deployed standard.

You misunderstand my statement. X9.68 supports all of
the X.509 certificate payloads required in the ISO 15782
profile for the fincvs industry. But the format is not
the same as that in the deployed X.509 standard. But a
DER encoding of some 170 bytes in X9.68 can carry the
same information content as that found in an 11-1200
byte X.509 certificate.

> ASN.1 is not such a barrier to deployment of PKI that any

I would say that given the freely available tools,
ASN.1 is hardly a barrier to deployment.

> party I am aware of is willing to forgo interoperability
> with the deployed X.509v3 base just for the sake of being
> able to avoid ASN.1 encoding.
> 
> The only justification for an incompatible data format is
> if the standard is going to support substantially different
> semantics that addresses a substantially different application
> domain, in the case of XKMS the specification is service
> oriented and the semantics are key centric as opposed to 
> certificate centric.

In the case of X9.68, the certificate format is domain
centric and not identity centric - there are no DNs, and
each domain certificate name uniquely identifies that
certificate as well as all of the certificates needed for
path validation.

> I don't believe that there is the slightest possibility
> that the Web Services community is going to adopt ASN.1
> as a compressed encoding layer. XML and ASN.1 are both 
> already complex enough without taking the cross product
> of both.

I'm sure that I am not alone in remaining hopeful that
the Web Services community will end up with viable,
efficient solutions that are simple and secure.

Phil

> 		Phill

Date: Mon, 16 Sep 2002 14:41:40 -0500
To: [email-masked]
From: Steve Tuecke <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: Steve Tuecke <[email-masked]>
Sender: [email-masked]

All,

A couple weeks ago, I proposed withdrawal of the Proxy Cert Profile from 
PKIX.  Russ argued against this, which led to posing the following 
straw-poll question:

>Should PKIX sanction the advancement of a proxy cert draft based on the 
>current fundamental approach?  We can argue about the details more later, 
>but the fundamental approach at issue is whether it is reasonable to use 
>end-entity public key certificates to sign proxy certificates. Possible 
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

There were 3 responses.  Russ Housley voted #3.  Phill Hallam-Baker 
suggested forming a new working group, which I would put in the #1 
category.  Denis Pinkas responded, but did not explicitly vote for one of 
these choices -- his closest statement to a vote was 'I do not have [a 
problem with using end-entity public key certificates to sign proxy 
certificates] as long as the draft is using everywhere "proxy certificate" 
and is NOT using the terminology "public key certificate"'.

So it seems the tally is 1 yes, 1 no, 1 abstain, and lots of 
apathy.  Anybody else care to weigh in on this issue?

-Steve

At 01:41 PM 9/9/2002, Hallam-Baker, Phillip wrote:
>Answer: Start a new group
>
>PKIX was formed to do one thing and has become a standing committee that
>will do anything, provided it is in ASN.1 syntax. That is a bad thing.
>
>I would much prefer to see the group split into two. Continuing PKIX would
>be tasked with simply moving the current RFCs through the standards track to
>Draft and Standard. PKIX-EXT would be tasked with developing extensions to
>PKIX where necessary.
>
>
>                 Phill

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Date: Mon, 16 Sep 2002 15:08:51 -0400
Subject: FWD: ;binary a/b design teams' summary / recommendation review
Sender: [email-masked]

Please take any discussion of this topic to the LDAPbis mail list.  I post 
it here to ensure that everyone who cares about this issue is aware it.

Russ

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 7:04 PM
To: [email-masked]
Subject: ;binary a/b design teams' summary / recommendation review

Two design teams were formed to consider how to clarify the specification of
the ;binary (and other) transfer option features in the LDAP "core"
technical specification.
   http://www.openldap.org/lists/ietf-ldapbis/200204/msg00073.html

This message provides a brief summary of the teams discussions, a combined
recommendation, and initiates a 2-week WG discussion period to determine
whether the WG consensus supports adopting the teams' recommendation.  Both
design teams are now disbanded.

While each team mission was to produce alternative text, both teams worked
together to ensure each understood the issues and to determine the areas of
contention.  One key area was the semantics of all user attribute search
requests. One camp (a cross section of both teams), basically, thought that
a server should choose between returning either the native encoding (if
defined and supported) and the binary (if supported) encoding.  One camp
thought that a server should only return values in their native encoding (to
avoid interoperability caused by a server choice).  After much debate, it
was found that both approaches are problematic.  In short, the first
approach is problematic in that imperatives required to ensure
interoperability caused by the server choice would limit the general
usefulness of all user attribute search requests. The second approach is
problematic because it requires redefinition of all user attributes requests
in a manner inconsistent with the existing technical specification.

It was clear that the camps were deadlocked and that it
would be difficult for either camp to garner WG consensus.

Removal of the ;binary feature (and all mention of transfer
options) was then discussed.  The teams concluded that,
given the known interoperability problems with ;binary, limitations of the
;binary features, and the unsuitability of proposed revisions of its
technical specification, the ;binary feature (and all mention of transfer
options) should be removed from the technical specification.

The teams recognized that removal of the ;binary feature
would raise some backwards compatibility issues and is an
area which subsequent work may be appropriate to pursue.

The WG is to consider the teams' proposal to remove ;binary feature (and all
mention of transfer options).  A two-week comment period is hereby initiated
on this proposal ending 24 May 2002.  Based upon your comments, the WG
chairs will gauge WG consensus and take appropriate actions.

-- LDAPbis WG chairs 

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Phil Griffin'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Mon, 16 Sep 2002 10:51:49 -0700
Sender: [email-masked]

> > I fail to see the value of an XML expression of deployed
> > X.509 semantics. I fail to see the value of an ASN.1
> > encoding to rival deployed XML specifications.

> I see much value in X.509 semantics, regardless of the
> form of their expression. XML markup is just another
> encoding rule for ASN.1 values.

I still fail to see the advantage to an incompatible syntax
for an existing deployed standard.

ASN.1 is not such a barrier to deployment of PKI that any
party I am aware of is willing to forgo interoperability
with the deployed X.509v3 base just for the sake of being
able to avoid ASN.1 encoding.

The only justification for an incompatible data format is
if the standard is going to support substantially different
semantics that addresses a substantially different application
domain, in the case of XKMS the specification is service
oriented and the semantics are key centric as opposed to 
certificate centric.

I don't believe that there is the slightest possibility
that the Web Services community is going to adopt ASN.1
as a compressed encoding layer. XML and ASN.1 are both 
already complex enough without taking the cross product
of both.

		Phill

Date: Mon, 16 Sep 2002 13:35:12 -0400
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: "Hallam-Baker, Phillip" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Hallam-Baker, Phillip wrote:

> Has any party commercial or non-comercial endorsed the 
> proposed 'standard' and committed to supporting it?

There are at least two firms that I am aware of that are
building support for this into their tools. Note that
X9.68 has only recently become a US national standard.
It is now being "proposed" as an international standard.

> It is one thing to get a bunch of people to agree to
> a proposal, quite another to persuade an industry to
> deploy.

Very true.

> I fail to see the value of an XML expression of deployed
> X.509 semantics. I fail to see the value of an ASN.1
> encoding to rival deployed XML specifications.
> 

I see much value in X.509 semantics, regardless of the
form of their expression. XML markup is just another
encoding rule for ASN.1 values.

Phil

> 		Phill
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: Friday, September 13, 2002 4:19 PM
>>To: [email-masked]; [email-masked]; [email-masked];
>>[email-masked]
>>Subject: RE: What happened to the OCSPv2 draft?
>>
>>
>>Of course, there already is a more efficient encoding for XML
>>markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
>>shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
>>and that exactly the same abstract values can be encoded in 
>>50+ bytes in
>>DER. The obvious conclusion is that for every canonical DER 
>>value there
>>is a canonical XER encoding that yields an XMl markup 
>>representation of 
>>that same value. Clearly messages can be stored and transferrd in DER
>> (which is not a particularly compact ASN.1 encoding, but  
>>which enjoys
>> tools are cheap  and readily available) and exploded into 
>>XML markup in 
>>resource rich environments.
>>
>>This is the thrust of the OASIS XML Common Biometric Format, the 2002
>>revision of the X9.84 biometric information management and security , 
>>the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
>>Trusted Time 
>>Stamp standards. It is also the core of the NWI proposal in 
>>ISO TC68/SC2 
>>based on the XMLEncoding Rules and the schema defined in the ASC X9.68
>>compressed domain certificate standard that moved forward in 
>>ISO this week.
>>If passed, this will result in a DER encoded certificate that is much
>>smaller
>>than the X.509 certificate format it is based on, and a 
>>completely XML 
>>certificate as well. The possibilities this will create to 
>>stir the pot
>>will be
>> interesting.
>> 
>>The idea of this approach is compelling for several reasons. 
>>It provides a
>>migration path into the XML space for ASN.1 defined specifications, it
>>allows
>>systems to be built  like my Biolojava tool kit that provide 
>>support  for
>>both XML
>>aware and ASN.1 aware applications, and it provides 
>>compression for XML
>>values. 
>>
>>But the really sweet  fallout of this is the simplicity of the XML
>>signature 
>>processing. It turns out to be almost equivalent  to the processing
>>description used currently for DER in the IETF SMIME standard. 
>>Anyone that can do SignedData using DER can, without nearly a
>>thought, do the same with XML markup and leverage the browser.
>>
>>And there are tools like mine emerging to support  these concepts, and
>>standards that will use them.
>>
>>Phil
>>
> 

Date: Mon, 16 Sep 2002 12:57:01 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call:draft-ietf-pkix-wlan-extns-02.txt
Sender: [email-masked]

Folks,

The authors have requested working group Last Call for the PKIX I-D 
"Wireless LAN Certificate Extensions and Attributes".  My review of network 
traffic since Yokohoma indicates that the new draft implements the minor 
changes requested by the list, and that there are no open issues.  IMHO, 
this document is ready to progress.

So, this email initiates a two week WG Last Call for "Wireless LAN 
Certificate Extensions and Attributes".  The current draft is available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt

Thanks,

Tim Polk

At 07:46 AM 9/16/02 -0400, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Public-Key Infrastructure (X.509) Working 
>Group of the IETF.
>
>         Title           : Wireless LAN Certificate Extensions and Attributes
>         Author(s)       : R. Housley, T. Moore
>         Filename        : draft-ietf-pkix-wlan-extns-02.txt
>         Pages           : 8
>         Date            : 2002-9-13
>
>This document defines two EAP extended key usage values and a public
>key certificate extension to carry Wireless LAN (WLAN) System Service
>identifiers (SSIDs).
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-pkix-wlan-extns-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-pkix-wlan-extns-02.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-wlan-extns-02.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt>

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Mon, 16 Sep 2002 08:04:18 -0700
Sender: [email-masked]

Has any party commercial or non-comercial endorsed the 
proposed 'standard' and committed to supporting it?

It is one thing to get a bunch of people to agree to
a proposal, quite another to persuade an industry to
deploy.

I fail to see the value of an XML expression of deployed
X.509 semantics. I fail to see the value of an ASN.1
encoding to rival deployed XML specifications.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 4:19 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value. Clearly messages can be stored and transferrd in DER
>  (which is not a particularly compact ASN.1 encoding, but  
> which enjoys
>  tools are cheap  and readily available) and exploded into 
> XML markup in 
> resource rich environments.
> 
> This is the thrust of the OASIS XML Common Biometric Format, the 2002
> revision of the X9.84 biometric information management and security , 
> the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
> Trusted Time 
> Stamp standards. It is also the core of the NWI proposal in 
> ISO TC68/SC2 
> based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> compressed domain certificate standard that moved forward in 
> ISO this week.
> If passed, this will result in a DER encoded certificate that is much
> smaller
> than the X.509 certificate format it is based on, and a 
> completely XML 
> certificate as well. The possibilities this will create to 
> stir the pot
> will be
>  interesting.
>  
> The idea of this approach is compelling for several reasons. 
> It provides a
> migration path into the XML space for ASN.1 defined specifications, it
> allows
> systems to be built  like my Biolojava tool kit that provide 
> support  for
> both XML
> aware and ASN.1 aware applications, and it provides 
> compression for XML
> values. 
> 
> But the really sweet  fallout of this is the simplicity of the XML
> signature 
> processing. It turns out to be almost equivalent  to the processing
> description used currently for DER in the IETF SMIME standard. 
> Anyone that can do SignedData using DER can, without nearly a
> thought, do the same with XML markup and leverage the browser.
> 
> And there are tools like mine emerging to support  these concepts, and
> standards that will use them.
> 
> Phil

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-02.txt
Date: Mon, 16 Sep 2002 07:46:48 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Wireless LAN Certificate Extensions and Attributes
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-wlan-extns-02.txt
	Pages		: 8
	Date		: 2002-9-13
	
This document defines two EAP extended key usage values and a public
key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-wlan-extns-02.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 16 Sep 2002 14:03:43 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>OCSP v2 should NOT expand its possibilities beyond certificate revocation
>checking and certainly should NOT try to expand its capabilities to cover
>certificate validation.
>
>To be more precise, I do not care about the expired OCSP v2 draft, but I
>care about fixing RFC 2560, while sticking to its original functionality:
>individual certificate revocation information status check.
>
>Having said that, we should correct the major problem that exists in
>RFC 2560, which is how the certificate can be defined.
>
>[...]

I agree with absolutely everything Denis has said.

[Pause.  Rereads post two more times]

Ah, I finally found something to disagree with: The tag for the OCTET STRING
is redundant :-).

All OCSP really needs is a more usable way to identify certs, and the CRL
locator would be useful too.  Both of these are trivial additions to OCSP
which could be easily added to 2560-bis, and don't require any v2, which was
adding all sorts of other stuff to the extent where it was almost a different
protocol.  If there's total opposition to making this tiny change to 2560-
bis, and since no-one has spoken out for the current v2 draft, I'll do the new
v2 draft myself (or do you want to do it Denis?).  It's only going to be a
page or so of text by the looks of it.

Peter.

Date: Mon, 16 Sep 2002 14:00:31 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

"Liaquat Khan" <[email-masked]> writes:

>I was thinking the OCSP responder could also use the serialNumber from the
>CertID to do this.

... except that the issuer DN has been smashed by the hashing, making it
impossible to locate the CRL even if you do know the serialNumber.

Peter.

Date: Mon, 16 Sep 2002 13:56:09 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Cc: [email-masked]
Sender: [email-masked]

"Hallam-Baker, Phillip" <[email-masked]> writes:

>>Todd's most recent effort was directed at removing me as chair of the
>>PKIX WG, by persuading someone to take my place, or create a new WG
>>for which I was not the chair, or to persuade the IESG or IAB that
>>PKIX was broken and needed to be fixed, and then, ultimately, to
>>convince the IAB & IESG that the IETF was broken and needed to be
>>fixed.
>
>And you foiled the plot by putting a fake timestamp on the moment at which
>the IESG and IAB were convinced?

He foiled the plot by using an X.509 cert from a public CA and having it
verified using COTS software (or was that how Todd started the plot?).

Peter :-).

Date: Sun, 15 Sep 2002 01:12:44 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

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

Denis Pinkas wrote:
> I do not care about OCSP v2: some documents die.
> 
> However, I care with OCSP(v1)bis. The Yokohama meeting report states:
> 
> "Roadmap, OCSP(v1)bis and PI documents in IESG queue."
> 
> The document is available at: http://www.imc.org/draft-ietf-pkix-rfc2560bis

I notice that this draft does not clarify the syntax of the nonce extension,
as discussed on this list in May-June. (The conclusion was that clients should
use an OCTET STRING as the encapsulated type.)

- -- 
David Hopwood <[email-masked]>

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

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Fri, 13 Sep 2002 19:19:18 -0400
Sender: [email-masked]

Of course, there already is a more efficient encoding for XML
markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
and that exactly the same abstract values can be encoded in 50+ bytes in
DER. The obvious conclusion is that for every canonical DER value there
is a canonical XER encoding that yields an XMl markup representation of 
that same value. Clearly messages can be stored and transferrd in DER
 (which is not a particularly compact ASN.1 encoding, but  which enjoys
 tools are cheap  and readily available) and exploded into XML markup in 
resource rich environments.

This is the thrust of the OASIS XML Common Biometric Format, the 2002
revision of the X9.84 biometric information management and security , 
the X9.96 XML Cryptographic Message Syntax, and the  X9.95 Trusted Time 
Stamp standards. It is also the core of the NWI proposal in ISO TC68/SC2 
based on the XMLEncoding Rules and the schema defined in the ASC X9.68
compressed domain certificate standard that moved forward in ISO this week.
If passed, this will result in a DER encoded certificate that is much
smaller
than the X.509 certificate format it is based on, and a completely XML 
certificate as well. The possibilities this will create to stir the pot
will be
 interesting.
 
The idea of this approach is compelling for several reasons. It provides a
migration path into the XML space for ASN.1 defined specifications, it
allows
systems to be built  like my Biolojava tool kit that provide support  for
both XML
aware and ASN.1 aware applications, and it provides compression for XML
values. 

But the really sweet  fallout of this is the simplicity of the XML
signature 
processing. It turns out to be almost equivalent  to the processing
description used currently for DER in the IETF SMIME standard. 
Anyone that can do SignedData using DER can, without nearly a
thought, do the same with XML markup and leverage the browser.

And there are tools like mine emerging to support  these concepts, and
standards that will use them.

Phil

Original Message:
-----------------
From: Hallam-Baker, Phillip [email-masked]
Date: Fri, 13 Sep 2002 09:46:35 -0700
To: [email-masked], [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?

No, I think it was because we have customers and the customers don't want to
send more data than is required, particularly the ones who are paying by the
kb over wireless links.

If you are using the 2048 bit RSA keys you have 512 bytes of incompressible
crypto information alone in a cert. You are going to struggle to get that
plus protocol packaging into a single ethernet frame.

If there is a point to developing another delegated path discovery and
validation algorithm it is to allow for shorter messages than XKMS in XML
text encoding. Of course we could just develop an efficient encoding for
XML.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 8:46 AM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> 
> 
> Hi Denis,
>     To make this easier to read, I will skip the part we agree on.
> 
> Here is the controversial topic: Do we need multiple ways of
> identifying a certificate. My contention is no. We need to
> decide on one and use that.
> 
> I see 2 reasonable options:
> 1. The current cert serial number and issuer name/key hash
> 2. The full certificate
> 
> I know in the past folks from VeriSign hated the second option. I
> believe this was because their certs were pretty large (with
> statements about limitations of liability, etc.).
> 
> At this stage, given the work that has gone in OCSPv1, I don't
> think it is worthwhile digging up this controversy again. The
> current option works fine for OCSP as long as you aren't asking
> OCSP to also do path creation for you. If you have already
> created one or more certificate chains, it isn't very hard
> to figure out the CA's public key for any certificate in that
> chain.
> 
> Makes sense?
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [email-masked]
> http://www.malpani.biz
> 
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [email-masked]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > Oops - too many messages just while I am transitioning....
> > >
> > > Steve, if I remember correctly, what we agreed on was that
> > > badly designed extensions can screw up a perfectly good
> > > protocol. So can badly designed implementations....
> > >
> > > Denis, I like the suggestion about allowing a client to include
> > > the CRLDP extension in requests.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > I don't like the suggestion of
> > > providing multiple means of identifying certificates - it
> > > adds more interoperability problems and doesn't add much to
> > > the protocol - assuming that we agree that OCSP was meant to
> > > provide the status of a certificate.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    CertificateSerialNumber  ::=  INTEGER
> >
> > You cannot directly know the DN of the CA. You have to use 
> a list of known
> > CAs and compute the hash over each of them to perform the 
> match. This is a
> > severe limitation.
> >
> > > For the former, all we need to do is define the extension. That
> > > really doesn't need work on a OCSPv2 at all.
> >
> > I agree that, for defining an extension for handling a 
> CRLDP extension in
> > requests, we do not need to define a v2 version, since it would be
> > applicable to v1.
> >
> > Regards,
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; [email-masked] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > Steve,
> > > >
> > > > You said:
> > > >
> > > > "Ambarish later recalled that I warned him about the 
> problems that
> > > > extensions to OCSP might engender, and he agreed that 
> they had come
> > > > to cause problems."
> > > >
> > > > I do agree we you.
> > > >
> > > > To come back to technical issues, the expired OCSP v2 draft
> > was expanding
> > > > its possibilities beyond certificate revocation 
> checking, whereas some
> > > > fixing on the deficiencies of RFC 2560 would have been 
> needed, in
> > > > particular, as pointed by Peter, more ways to select the
> > certificate to be
> > > > checked.
> > > >
> > > > OCSP v2 should NOT expand its possibilities beyond
> > certificate revocation
> > > > checking and certainly should NOT try to expand its
> > capabilities to cover
> > > > certificate validation.
> > > >
> > > > To be more precise, I do not care about the expired OCSP v2
> > draft, but I
> > > > care about fixing RFC 2560, while sticking to its original
> > functionality:
> > > > individual certificate revocation information status check.
> > > >
> > > > Having said that, we should correct the major problem 
> that exists in
> > > > RFC 2560, which is how the certificate can be defined.
> > > >
> > > > The proposal in the last draft
> > (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > > >
> > > > ReqCert  ::= CHOICE {
> > > >    certID            CertID,
> > > >    issuerSerial      [0] IssuerandSerialNumber,
> > > >    pKCert            [1] Certificate,
> > > >    name              [2] GeneralName,
> > > >    certHash          [3] OCTET STRING}
> > > >
> > > > CertID          ::=     SEQUENCE {
> > > >    hashAlgorithm       AlgorithmIdentifier,
> > > >    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> > > >    issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> > > >    serialNumber        CertificateSerialNumber }
> > > >
> > > > In addition, RFC 2560 includes a serviceLocator request
> > extension, which
> > > > is nice when an OCSP service is supported in the background.
> > However, it
> > > > does not include any extension when a CRL is supported in the
> > background.
> > > > This means that the OCSP server cannot know in general where
> > the CRL to be
> > > > used is located.
> > > >
> > > > :-(
> > > >
> > > > One way would be to send the whole certificate (this is NOT
> > possible with
> > > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > > responder,
> > > > but another possibility would be to use an extension 
> where the CDP
> > > > information present in the certificate would copied and 
> pasted in that
> > > > extension. Then, using issuerSerial, the OCSP responder can
> > > > perform the CRL
> > > > check and to transform it into an OCSP response.
> > > >
> > > > Such extension would look like:
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > > 8.X     CRL Locator
> > > >
> > > > An OCSP server may be operated in a mode whereby the 
> server receives a
> > > > request and fetches the CRL which authoritative for the 
> identified
> > > > certificate. The crlLocator request extension is 
> defined for this
> > > > purpose.
> > > > This extension is included as one of the 
> singleRequestExtensions in
> > > > requests.
> > > >
> > > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { 
> id-pkix-ocsp X }
> > > >
> > > >    CrlLocator ::= CRLDistributionPoints
> > > >
> > > > The value for this field is obtained from the corresponding
> > field in the
> > > > subject certificate.
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > >
> > > > So my proposal would be to issue a new OCSP v2 draft, only
> > > > including these
> > > > two changes. Anything else I forgot ?
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> >
> 

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date: Fri, 13 Sep 2002 11:43:15 -0700
From: Jeff Jacoby <[email-masked]>
Organization: RSA Security, Inc.
To: "[email-masked] '" <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Denis Pinkas wrote:
> Florian,

[snip]

> > Thus we should add an extension regarding the time of revocation
> > checking - to allow the validation protocol to use OCSP while
> fulfilling
> > the DPV-DPD requirements:
> 
> > "The client can request that the server determine the certificate
> > validity at a time other than the current time. The DPV server MUST
> > obtain revocation status information for the validation time in the
> > client request." - DPV-DPD requirements document
> 
> I do not think that adding a parameter in the request to specify a time
> in
> the past (which is I guess what you are proposing) is necessary.
> 

I've never quite understood the utility of the archive cutoff value.

I find the "contribute to a proof" arguement, in section 4.4.4, rather
vague.  
So I know the responder archives data for the last 7 years.  

So what?  

If I can't query the responder to see if a cert was revoked 6.5 years
ago
how does knowing the cutoff was 7 year ago really contribute to a proof

I think having a request parameter specify a time in the past better 
enables a client to take advantage of the cutoff information.  I can see 
it's not strictly necessary, but it would be really nice to have.

> A signature has to be validated close to the time it was made and thus
> the
> revocation status information has to be captured close to that time.

I would argue this is too limiting.  If revocation information is
archived then we shouldn't restrict an RP from getting that information
no matter when the signature was created.

Here's an example (somewhat contrived):  

  - Executive of company E signs some financial documents/contracts.

  - After a short time the certificate is revoked (say, the Executive
    left the company).

  - A year later company E is under investigation for shady financial
    dealings, which may include the above signed document.

Isn't it reasonable for the investigators to determine--a year after the
signature was created--if the cert was revoked then?

> We already have the archive cutoff in case an OCSP responder chooses
> to retain revocation information beyond a certificate's expiration.

My apologies if I've mis-understood some of these issues.

Jeff
-- 
Jeff Jacoby, Principal Programmer                
RSA Security Inc., SMDC                    [email-masked]
2955 Campus Dr., Ste. 400                  (650) 295-7569
San Mateo, CA  94403

Date: Fri, 13 Sep 2002 18:55:27 +0200
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: Marc Poulaud <[email-masked]>
Cc: [email-masked]
Subject: Re: CDP CRL format?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Marc Poulaud wrote:
> In relation to a CRL that is pointed at by the URI contained in a cert's 
> CDP, what *typically* might you expect the format of the CRL to be in? 
> I'd thought this would be an x.509x2 CRL wrapped in a PKCS#7.
>  
> Do some applications or platforms expect/want something else?

Some applications do want Base64 or binary DER encoded CRLs (Netscape does).

> I've noticed that on a particular server that hold CRLs (from a Verisign 
> CA), there are a number of files of different formats. One file is 
> LatestCRL and another is LatestCRL.crl (amongst others). Anybody know 
> what the difference might be?

Probably to handle the mimetype directly within the web-server (take a look
at the .crl datatype handling in the example apache config file).

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                      [email-masked]
http://www.openca.org                            Tel.:   +39 (0)59  270  094
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

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

--------------ms040803070005060000010009--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Fri, 13 Sep 2002 09:46:35 -0700
Sender: [email-masked]

No, I think it was because we have customers and the customers don't want to
send more data than is required, particularly the ones who are paying by the
kb over wireless links.

If you are using the 2048 bit RSA keys you have 512 bytes of incompressible
crypto information alone in a cert. You are going to struggle to get that
plus protocol packaging into a single ethernet frame.

If there is a point to developing another delegated path discovery and
validation algorithm it is to allow for shorter messages than XKMS in XML
text encoding. Of course we could just develop an efficient encoding for
XML.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 8:46 AM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> 
> 
> Hi Denis,
>     To make this easier to read, I will skip the part we agree on.
> 
> Here is the controversial topic: Do we need multiple ways of
> identifying a certificate. My contention is no. We need to
> decide on one and use that.
> 
> I see 2 reasonable options:
> 1. The current cert serial number and issuer name/key hash
> 2. The full certificate
> 
> I know in the past folks from VeriSign hated the second option. I
> believe this was because their certs were pretty large (with
> statements about limitations of liability, etc.).
> 
> At this stage, given the work that has gone in OCSPv1, I don't
> think it is worthwhile digging up this controversy again. The
> current option works fine for OCSP as long as you aren't asking
> OCSP to also do path creation for you. If you have already
> created one or more certificate chains, it isn't very hard
> to figure out the CA's public key for any certificate in that
> chain.
> 
> Makes sense?
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani                                         650.759.9045
> Malpani Consulting Services                      [email-masked]
> http://www.malpani.biz
> 
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [email-masked]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > Oops - too many messages just while I am transitioning....
> > >
> > > Steve, if I remember correctly, what we agreed on was that
> > > badly designed extensions can screw up a perfectly good
> > > protocol. So can badly designed implementations....
> > >
> > > Denis, I like the suggestion about allowing a client to include
> > > the CRLDP extension in requests.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > I don't like the suggestion of
> > > providing multiple means of identifying certificates - it
> > > adds more interoperability problems and doesn't add much to
> > > the protocol - assuming that we agree that OCSP was meant to
> > > provide the status of a certificate.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    CertificateSerialNumber  ::=  INTEGER
> >
> > You cannot directly know the DN of the CA. You have to use 
> a list of known
> > CAs and compute the hash over each of them to perform the 
> match. This is a
> > severe limitation.
> >
> > > For the former, all we need to do is define the extension. That
> > > really doesn't need work on a OCSPv2 at all.
> >
> > I agree that, for defining an extension for handling a 
> CRLDP extension in
> > requests, we do not need to define a v2 version, since it would be
> > applicable to v1.
> >
> > Regards,
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; [email-masked] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > Steve,
> > > >
> > > > You said:
> > > >
> > > > "Ambarish later recalled that I warned him about the 
> problems that
> > > > extensions to OCSP might engender, and he agreed that 
> they had come
> > > > to cause problems."
> > > >
> > > > I do agree we you.
> > > >
> > > > To come back to technical issues, the expired OCSP v2 draft
> > was expanding
> > > > its possibilities beyond certificate revocation 
> checking, whereas some
> > > > fixing on the deficiencies of RFC 2560 would have been 
> needed, in
> > > > particular, as pointed by Peter, more ways to select the
> > certificate to be
> > > > checked.
> > > >
> > > > OCSP v2 should NOT expand its possibilities beyond
> > certificate revocation
> > > > checking and certainly should NOT try to expand its
> > capabilities to cover
> > > > certificate validation.
> > > >
> > > > To be more precise, I do not care about the expired OCSP v2
> > draft, but I
> > > > care about fixing RFC 2560, while sticking to its original
> > functionality:
> > > > individual certificate revocation information status check.
> > > >
> > > > Having said that, we should correct the major problem 
> that exists in
> > > > RFC 2560, which is how the certificate can be defined.
> > > >
> > > > The proposal in the last draft
> > (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > > >
> > > > ReqCert  ::= CHOICE {
> > > >    certID            CertID,
> > > >    issuerSerial      [0] IssuerandSerialNumber,
> > > >    pKCert            [1] Certificate,
> > > >    name              [2] GeneralName,
> > > >    certHash          [3] OCTET STRING}
> > > >
> > > > CertID          ::=     SEQUENCE {
> > > >    hashAlgorithm       AlgorithmIdentifier,
> > > >    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> > > >    issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> > > >    serialNumber        CertificateSerialNumber }
> > > >
> > > > In addition, RFC 2560 includes a serviceLocator request
> > extension, which
> > > > is nice when an OCSP service is supported in the background.
> > However, it
> > > > does not include any extension when a CRL is supported in the
> > background.
> > > > This means that the OCSP server cannot know in general where
> > the CRL to be
> > > > used is located.
> > > >
> > > > :-(
> > > >
> > > > One way would be to send the whole certificate (this is NOT
> > possible with
> > > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > > responder,
> > > > but another possibility would be to use an extension 
> where the CDP
> > > > information present in the certificate would copied and 
> pasted in that
> > > > extension. Then, using issuerSerial, the OCSP responder can
> > > > perform the CRL
> > > > check and to transform it into an OCSP response.
> > > >
> > > > Such extension would look like:
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > > 8.X     CRL Locator
> > > >
> > > > An OCSP server may be operated in a mode whereby the 
> server receives a
> > > > request and fetches the CRL which authoritative for the 
> identified
> > > > certificate. The crlLocator request extension is 
> defined for this
> > > > purpose.
> > > > This extension is included as one of the 
> singleRequestExtensions in
> > > > requests.
> > > >
> > > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { 
> id-pkix-ocsp X }
> > > >
> > > >    CrlLocator ::= CRLDistributionPoints
> > > >
> > > > The value for this field is obtained from the corresponding
> > field in the
> > > > subject certificate.
> > > >
> > > > 
> ==================================================================
> > > > =========
> > > >
> > > > So my proposal would be to issue a new OCSP v2 draft, only
> > > > including these
> > > > two changes. Anything else I forgot ?
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> >
> 

From: "Ambarish Malpani" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Fri, 13 Sep 2002 08:45:51 -0700
Importance: Normal
Sender: [email-masked]

Hi Denis,
    To make this easier to read, I will skip the part we agree on.

Here is the controversial topic: Do we need multiple ways of
identifying a certificate. My contention is no. We need to
decide on one and use that.

I see 2 reasonable options:
1. The current cert serial number and issuer name/key hash
2. The full certificate

I know in the past folks from VeriSign hated the second option. I
believe this was because their certs were pretty large (with
statements about limitations of liability, etc.).

At this stage, given the work that has gone in OCSPv1, I don't
think it is worthwhile digging up this controversy again. The
current option works fine for OCSP as long as you aren't asking
OCSP to also do path creation for you. If you have already
created one or more certificate chains, it isn't very hard
to figure out the CA's public key for any certificate in that
chain.

Makes sense?
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 7:58 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: Re: What happened to the OCSPv2 draft?
>
>
> Ambarish,
>
> > Oops - too many messages just while I am transitioning....
> >
> > Steve, if I remember correctly, what we agreed on was that
> > badly designed extensions can screw up a perfectly good
> > protocol. So can badly designed implementations....
> >
> > Denis, I like the suggestion about allowing a client to include
> > the CRLDP extension in requests.
>
> Good. This is a point on which we both agree. :-)
>
> > I don't like the suggestion of
> > providing multiple means of identifying certificates - it
> > adds more interoperability problems and doesn't add much to
> > the protocol - assuming that we agree that OCSP was meant to
> > provide the status of a certificate.
>
> The current ways to specify the certificate are not that easy.
>
>    CertID ::=     SEQUENCE {
>        hashAlgorithm       AlgorithmIdentifier,
>        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>        issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
>        serialNumber        CertificateSerialNumber }
>
>    CertificateSerialNumber  ::=  INTEGER
>
> You cannot directly know the DN of the CA. You have to use a list of known
> CAs and compute the hash over each of them to perform the match. This is a
> severe limitation.
>
> > For the former, all we need to do is define the extension. That
> > really doesn't need work on a OCSPv2 at all.
>
> I agree that, for defining an extension for handling a CRLDP extension in
> requests, we do not need to define a v2 version, since it would be
> applicable to v1.
>
> Regards,
>
> Denis
>
> > Regards,
> > Ambarish
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > > Sent: Thursday, September 12, 2002 1:48 AM
> > > To: Stephen Kent
> > > Cc: Peter Williams; [email-masked] '
> > > Subject: Re: What happened to the OCSPv2 draft?
> > >
> > >
> > >
> > > Steve,
> > >
> > > You said:
> > >
> > > "Ambarish later recalled that I warned him about the problems that
> > > extensions to OCSP might engender, and he agreed that they had come
> > > to cause problems."
> > >
> > > I do agree we you.
> > >
> > > To come back to technical issues, the expired OCSP v2 draft
> was expanding
> > > its possibilities beyond certificate revocation checking, whereas some
> > > fixing on the deficiencies of RFC 2560 would have been needed, in
> > > particular, as pointed by Peter, more ways to select the
> certificate to be
> > > checked.
> > >
> > > OCSP v2 should NOT expand its possibilities beyond
> certificate revocation
> > > checking and certainly should NOT try to expand its
> capabilities to cover
> > > certificate validation.
> > >
> > > To be more precise, I do not care about the expired OCSP v2
> draft, but I
> > > care about fixing RFC 2560, while sticking to its original
> functionality:
> > > individual certificate revocation information status check.
> > >
> > > Having said that, we should correct the major problem that exists in
> > > RFC 2560, which is how the certificate can be defined.
> > >
> > > The proposal in the last draft
> (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > >
> > > ReqCert  ::= CHOICE {
> > >    certID            CertID,
> > >    issuerSerial      [0] IssuerandSerialNumber,
> > >    pKCert            [1] Certificate,
> > >    name              [2] GeneralName,
> > >    certHash          [3] OCTET STRING}
> > >
> > > CertID          ::=     SEQUENCE {
> > >    hashAlgorithm       AlgorithmIdentifier,
> > >    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> > >    issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
> > >    serialNumber        CertificateSerialNumber }
> > >
> > > In addition, RFC 2560 includes a serviceLocator request
> extension, which
> > > is nice when an OCSP service is supported in the background.
> However, it
> > > does not include any extension when a CRL is supported in the
> background.
> > > This means that the OCSP server cannot know in general where
> the CRL to be
> > > used is located.
> > >
> > > :-(
> > >
> > > One way would be to send the whole certificate (this is NOT
> possible with
> > > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > > responder,
> > > but another possibility would be to use an extension where the CDP
> > > information present in the certificate would copied and pasted in that
> > > extension. Then, using issuerSerial, the OCSP responder can
> > > perform the CRL
> > > check and to transform it into an OCSP response.
> > >
> > > Such extension would look like:
> > >
> > > ==================================================================
> > > =========
> > > 8.X     CRL Locator
> > >
> > > An OCSP server may be operated in a mode whereby the server receives a
> > > request and fetches the CRL which authoritative for the identified
> > > certificate. The crlLocator request extension is defined for this
> > > purpose.
> > > This extension is included as one of the singleRequestExtensions in
> > > requests.
> > >
> > >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
> > >
> > >    CrlLocator ::= CRLDistributionPoints
> > >
> > > The value for this field is obtained from the corresponding
> field in the
> > > subject certificate.
> > >
> > > ==================================================================
> > > =========
> > >
> > > So my proposal would be to issue a new OCSP v2 draft, only
> > > including these
> > > two changes. Anything else I forgot ?
> > >
> > > Regards,
> > >
> > > Denis
> > >
>

Date: Fri, 13 Sep 2002 16:57:37 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Ambarish,
 
> Oops - too many messages just while I am transitioning....
> 
> Steve, if I remember correctly, what we agreed on was that
> badly designed extensions can screw up a perfectly good
> protocol. So can badly designed implementations....
> 
> Denis, I like the suggestion about allowing a client to include
> the CRLDP extension in requests. 

Good. This is a point on which we both agree. :-)

> I don't like the suggestion of
> providing multiple means of identifying certificates - it
> adds more interoperability problems and doesn't add much to
> the protocol - assuming that we agree that OCSP was meant to
> provide the status of a certificate.

The current ways to specify the certificate are not that easy.

   CertID ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   CertificateSerialNumber  ::=  INTEGER

You cannot directly know the DN of the CA. You have to use a list of known
CAs and compute the hash over each of them to perform the match. This is a
severe limitation.
 
> For the former, all we need to do is define the extension. That
> really doesn't need work on a OCSPv2 at all.

I agree that, for defining an extension for handling a CRLDP extension in
requests, we do not need to define a v2 version, since it would be
applicable to v1.

Regards,

Denis
 
> Regards,
> Ambarish
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > Sent: Thursday, September 12, 2002 1:48 AM
> > To: Stephen Kent
> > Cc: Peter Williams; [email-masked] '
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> >
> > Steve,
> >
> > You said:
> >
> > "Ambarish later recalled that I warned him about the problems that
> > extensions to OCSP might engender, and he agreed that they had come
> > to cause problems."
> >
> > I do agree we you.
> >
> > To come back to technical issues, the expired OCSP v2 draft was expanding
> > its possibilities beyond certificate revocation checking, whereas some
> > fixing on the deficiencies of RFC 2560 would have been needed, in
> > particular, as pointed by Peter, more ways to select the certificate to be
> > checked.
> >
> > OCSP v2 should NOT expand its possibilities beyond certificate revocation
> > checking and certainly should NOT try to expand its capabilities to cover
> > certificate validation.
> >
> > To be more precise, I do not care about the expired OCSP v2 draft, but I
> > care about fixing RFC 2560, while sticking to its original functionality:
> > individual certificate revocation information status check.
> >
> > Having said that, we should correct the major problem that exists in
> > RFC 2560, which is how the certificate can be defined.
> >
> > The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:
> >
> > ReqCert  ::= CHOICE {
> >    certID            CertID,
> >    issuerSerial      [0] IssuerandSerialNumber,
> >    pKCert            [1] Certificate,
> >    name              [2] GeneralName,
> >    certHash          [3] OCTET STRING}
> >
> > CertID          ::=     SEQUENCE {
> >    hashAlgorithm       AlgorithmIdentifier,
> >    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >    issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
> >    serialNumber        CertificateSerialNumber }
> >
> > In addition, RFC 2560 includes a serviceLocator request extension, which
> > is nice when an OCSP service is supported in the background. However, it
> > does not include any extension when a CRL is supported in the background.
> > This means that the OCSP server cannot know in general where the CRL to be
> > used is located.
> >
> > :-(
> >
> > One way would be to send the whole certificate (this is NOT possible with
> > RFC 2560) so that the CDP can be extracted by the receiving OCSP
> > responder,
> > but another possibility would be to use an extension where the CDP
> > information present in the certificate would copied and pasted in that
> > extension. Then, using issuerSerial, the OCSP responder can
> > perform the CRL
> > check and to transform it into an OCSP response.
> >
> > Such extension would look like:
> >
> > ==================================================================
> > =========
> > 8.X     CRL Locator
> >
> > An OCSP server may be operated in a mode whereby the server receives a
> > request and fetches the CRL which authoritative for the identified
> > certificate. The crlLocator request extension is defined for this
> > purpose.
> > This extension is included as one of the singleRequestExtensions in
> > requests.
> >
> >    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
> >
> >    CrlLocator ::= CRLDistributionPoints
> >
> > The value for this field is obtained from the corresponding field in the
> > subject certificate.
> >
> > ==================================================================
> > =========
> >
> > So my proposal would be to issue a new OCSP v2 draft, only
> > including these
> > two changes. Anything else I forgot ?
> >
> > Regards,
> >
> > Denis
> >

Date: Fri, 13 Sep 2002 16:57:01 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Florian Oelmaier <[email-masked]>
CC: "[email-masked] '" <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Florian,

> > OCSP v2 should NOT expand its possibilities beyond certificate revocation
> > checking and certainly should NOT try to expand its capabilities to cover
> > certificate validation.
> 
> Although this bears some odds from a marketing perspective, I can see
> your arguments and agree to them.
> 
> > To be more precise, I do not care about the expired OCSP v2 draft, but I
> > care about fixing RFC 2560, while sticking to its original functionality:
> > individual certificate revocation information status check.
> 
> Agree.
> 
> > Having said that, we should correct the major problem that exists in
> > RFC 2560, which is how the certificate can be defined.
> 
> [...]
> 
> > So my proposal would be to issue a new OCSP v2 draft, only including these
> > two changes. Anything else I forgot ?
 
> It would be nice to streamline OCSP so that it can be used as some sort
> of "revocation service provider" for one of the upcoming validation
> protocols - I think that is what you all have in mind.
 
> Thus we should add an extension regarding the time of revocation
> checking - to allow the validation protocol to use OCSP while fulfilling
> the DPV-DPD requirements:
 
> "The client can request that the server determine the certificate
> validity at a time other than the current time. The DPV server MUST
> obtain revocation status information for the validation time in the
> client request." - DPV-DPD requirements document

I do not think that adding a parameter in the request to specify a time in
the past (which is I guess what you are proposing) is necessary.

A signature has to be validated close to the time it was made and thus the
revocation status information has to be captured close to that time. 
We already have the archive cutoff in case an OCSP responder chooses
to retain revocation information beyond a certificate's expiration.

Denis 

> --
> Florian Oelmaier
> SyTrust

From: Kefeng Chen <[email-masked]>
To: "'Marc Poulaud'" <[email-masked]>, [email-masked]
Subject: RE: CDP CRL format?
Date: Fri, 13 Sep 2002 08:53:35 -0400
Sender: [email-masked]

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

Sometime people publish both binary formatted CRL and base64 formatted CRL.
But they are all X.509 v2 CRL.
 
Kefeng

-----Original Message-----
From: Marc Poulaud [mailto:[email-masked]]
Sent: Friday, September 13, 2002 6:14 AM
To: [email-masked]
Subject: CDP CRL format?

In relation to a CRL that is pointed at by the URI contained in a cert's
CDP, what *typically* might you expect the format of the CRL to be in? I'd
thought this would be an x.509x2 CRL wrapped in a PKCS#7.
 
Do some applications or platforms expect/want something else?
 
I've noticed that on a particular server that hold CRLs (from a Verisign
CA), there are a number of files of different formats. One file is LatestCRL
and another is LatestCRL.crl (amongst others). Anybody know what the
difference might be?
 
Thanks,

Marc 
______________________________

iSolve Ltd
Making eTrust happen
 
Tel:     +44 (0)7718 209 990
Email:  [email-masked] <mailto:[email-masked]> 
Web:   www.i-solve.co.uk <http://www.i-solve.co.uk/> 
______________________________

------_=_NextPart_001_01C25B24.92738630
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff 
size=2>Sometime people&nbsp;publish both binary formatted CRL and base64 
formatted CRL.</FONT></SPAN></DIV>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff size=2>But 
they are all X.509 v2 CRL.</FONT></SPAN></DIV>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=124345212-13092002><FONT face=Arial color=#0000ff 
size=2>Kefeng</FONT></SPAN></DIV>
<DIV><SPAN class=124345212-13092002></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Marc Poulaud 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, September 13, 2002 
  6:14 AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> CDP CRL 
  format?<BR><BR></FONT></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial size=2>In relation to a 
  CRL that is pointed at by the URI contained in a cert's CDP, what *typically* 
  might you expect the format of the CRL to be in? I'd thought this would be an 
  x.509x2 CRL wrapped in&nbsp;a PKCS#7.</FONT></SPAN></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial size=2>Do some 
  applications or platforms expect/want something else?</FONT></SPAN></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial size=2>I've noticed that 
  on a particular server that hold CRLs (from a Verisign CA), there are a number 
  of files of different formats. One file is LatestCRL and another is 
  LatestCRL.crl (amongst others). Anybody know what the difference might 
  be?</FONT></SPAN></DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=490460210-13092002><FONT face=Arial 
  size=2>Thanks,</FONT></SPAN></DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial size=2>
  <P><FONT size=7><FONT 
  face="French Script MT"><EM>Marc</EM>&nbsp;</FONT></FONT><BR>______________________________</FONT></P></DIV>
  <DIV><FONT face=Arial size=2>iSolve Ltd</FONT></DIV>
  <DIV><FONT face=Arial size=2><EM>Making eTrust happen</EM></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Tel:&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)7718 209 
  990</FONT></DIV>
  <DIV><FONT face=Arial size=2>Email:&nbsp;<A 
  href="mailto:[email-masked]">[email-masked]</A></FONT></DIV>
  <DIV><FONT face=Arial size=2>Web:&nbsp;&nbsp; <A 
  href="http://www.i-solve.co.uk/">www.i-solve.co.uk</A></FONT></DIV>
  <DIV><FONT face=Arial 
size=2>______________________________</FONT></DIV></FONT>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C25B24.92738630--

From: "Marc Poulaud" <[email-masked]>
To: <[email-masked]>
Subject: CDP CRL format?
Date: Fri, 13 Sep 2002 11:14:13 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C25B16.B09A3720
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In relation to a CRL that is pointed at by the URI contained in a cert's
CDP, what *typically* might you expect the format of the CRL to be in? I'd
thought this would be an x.509x2 CRL wrapped in a PKCS#7.

Do some applications or platforms expect/want something else?

I've noticed that on a particular server that hold CRLs (from a Verisign
CA), there are a number of files of different formats. One file is LatestCRL
and another is LatestCRL.crl (amongst others). Anybody know what the
difference might be?

Thanks,
Marc
______________________________

iSolve Ltd
Making eTrust happen

Tel:     +44 (0)7718 209 990
Email: [email-masked]
Web:   www.i-solve.co.uk
______________________________

------=_NextPart_000_001B_01C25B16.B09A3720
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial size=3D2>In =
relation to a CRL=20
that is pointed at by the URI contained in a cert's CDP, what =
*typically* might=20
you expect the format of the CRL to be in? I'd thought this would be an =
x.509x2=20
CRL wrapped in&nbsp;a PKCS#7.</FONT></SPAN></DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial size=3D2>Do =
some applications=20
or platforms expect/want something else?</FONT></SPAN></DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial size=3D2>I've =
noticed that on=20
a particular server that hold CRLs (from a Verisign CA), there are a =
number of=20
files of different formats. One file is LatestCRL and another is =
LatestCRL.crl=20
(amongst others). Anybody know what the difference might =
be?</FONT></SPAN></DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D490460210-13092002><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<P><FONT size=3D7><FONT=20
face=3D"French Script =
MT"><EM>Marc</EM>&nbsp;</FONT></FONT><BR>______________________________</=
FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2>iSolve Ltd</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><EM>Making eTrust =
happen</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Tel:&nbsp;&nbsp;&nbsp;&nbsp; +44 =
(0)7718 209=20
990</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Email:&nbsp;<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>=
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Web:&nbsp;&nbsp; <A=20
href=3D"http://www.i-solve.co.uk/">www.i-solve.co.uk</A></FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>______________________________</FONT></DIV></FONT>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01C25B16.B09A3720--

Date: Fri, 13 Sep 2002 16:02:34 +1200
From: "Joji Jacob" <[email-masked]>
To: "<"<[email-masked]>
Subject: un subscribe
Sender: [email-masked]

--------------------------------------------------------------------------------------
Disclaimer:
"The information contained in this document is confidential to the addressee(s) and
 may be legally privileged.   Any view or opinions expressed are those of the author
 and may not be those of the organisation to which the author belongs.  If you have
 received this e-mail message in error please delete it and notify me. Thank you."
--------------------------------------------------------------------------------------

Date: Thu, 12 Sep 2002 21:48:44 -0400
From: [email-masked]
To: [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Sender: [email-masked]

As I recall, the OCSPv2 draft was collateral damage in the DPD/DPV wars.  While 
there were some changes to the base specification, the biggest enhancements 
were focused on DPV.   If memory serves, sometimes DPV was in the "core" v2 
specification, and sometimes in a separate document.  (By "core", I mean 
certificate status rather than DPV.)  Either way, the core and DPV tended to be 
worked in tandem.
 
Of course, the DPV portion of the specification got stuck while we discussed 
the requirements document.  There was not a big push to progress the OCSPv2 
specification without the DPV work.

I have the impression that has changed... from this thread, there seems to be 
sufficient interest to resume work on the OCSP core functionality regardless of 
the outcome on DPV.

Please note - I am not choosing sides in the *new* debate (change the base 
message versus only define new extensions).  If the needed functionality can be 
implemented with new extensions, great.  If the basic meesage needs to be 
updated, that's okay too.  (That's why the request syntax has a version number!)

Tim

From: "Housley, Russ" <[email-masked]>
To: "Manger, James H" <[email-masked]>
Cc: [email-masked]
Date: Thu, 12 Sep 2002 12:15:04 -0400
Subject: Re: Logos: 04: ~editorial comments
Sender: [email-masked]

James:

Thanks for your careful reading of the document.  These are all good 
comments, and I agree with all of them except the background.  I do not 
think that you proposal allows the inclusion of both a foreground and a 
background logotypes.

Russ

At 07:27 PM 9/5/2002 +1000, Manger, James H wrote:

>1.
>The URI fields (imageURI, audioURI and refStructURI) are all a SEQUENCE OF
>IA5String.  There is no mention about why multiple URIs can be included or
>how they should be handled.  I am guessing that they are supposed to be
>alternative URIs for exactly the same item.  Consequently, a client can use
>any URI from the sequence.  If a URI fails, the client should try another.
>If so, a sentence to that affect would help.
>
>2.
>Renaming the imageFormat and audioFormat fields to imageSubtype and
>audioSubtype should make it clearer (in code, not just an ASN.1 comment)
>that the fields hold MIME subtypes.
>
>3.
>Community, issuer, subject & loyalty types tell you what a logo is related
>to.  Whether a logo can be used as a background image is a different style
>of information.  Instead of defining id-logo-background, how about including
>a flag in LogotypeImageInfo.
>         LogotypeImageInfo ::= SEQUENCE {
>                 ...
>                 background      BOOLEAN DEFAULT FALSE }
>
>         If background is true it indicates that the image is appropriate
>         for use as a background image for other certificate details, in
>which case
>         it MUST allow black text placed over the image to be clearly
>readable.
>
>4.
>That logos can - to some degree - circumvent name constraints is understood
>and explained in the Security considerations section.  A client can take
>steps to minimise this risk by, for instance, consistently displaying logos
>in a separate, clearly delineated, section of the screen -- so at least a
>careful user would not be fooled.  Using a logo as a background image seems
>to make this much harder -- now the client would need to, say, make the logo
>wobble for a careful user to be able to distinguish what come from the logo
>and what is generated by the (trusted) client.  Perhaps background images
>should not be supported.
>
>
> > ----------
> > From: [email-masked] [SMTP:[email-masked]]
> > Sent: Wednesday, 4 September 2002 9:57 pm
> >
> >       Title           : Internet X.509 Public Key Infrastructure Logotypes
> > in X.509 certificates
> >       Author(s)       : S. Santesson, R. Housley, T. Freeman
> >       Filename        : draft-ietf-pkix-logotypes-04.txt
> >       Pages           : 19
> >       Date            : 2002-9-3
> >
> > This document specifies a certificate extension for including logotypes in
> > public key certificates and attribute certificates.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-04.txt
> >

From: "Ambarish Malpani" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Peter Williams" <[email-masked]>, <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Thu, 12 Sep 2002 11:07:45 -0700
Importance: Normal
Sender: [email-masked]

Oops - too many messages just while I am transitioning....

Steve, if I remember correctly, what we agreed on was that
badly designed extensions can screw up a perfectly good
protocol. So can badly designed implementations....

Denis, I like the suggestion about allowing a client to include
the CRLDP extension in requests. I don't like the suggestion of
providing multiple means of identifying certificates - it
adds more interoperability problems and doesn't add much to
the protocol - assuming that we agree that OCSP was meant to
provide the status of a certificate.

For the former, all we need to do is define the extension. That
really doesn't need work on a OCSPv2 at all.

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 12, 2002 1:48 AM
> To: Stephen Kent
> Cc: Peter Williams; [email-masked] '
> Subject: Re: What happened to the OCSPv2 draft?
>
>
>
> Steve,
>
> You said:
>
> "Ambarish later recalled that I warned him about the problems that
> extensions to OCSP might engender, and he agreed that they had come
> to cause problems."
>
> I do agree we you.
>
> To come back to technical issues, the expired OCSP v2 draft was expanding
> its possibilities beyond certificate revocation checking, whereas some
> fixing on the deficiencies of RFC 2560 would have been needed, in
> particular, as pointed by Peter, more ways to select the certificate to be
> checked.
>
> OCSP v2 should NOT expand its possibilities beyond certificate revocation
> checking and certainly should NOT try to expand its capabilities to cover
> certificate validation.
>
> To be more precise, I do not care about the expired OCSP v2 draft, but I
> care about fixing RFC 2560, while sticking to its original functionality:
> individual certificate revocation information status check.
>
> Having said that, we should correct the major problem that exists in
> RFC 2560, which is how the certificate can be defined.
>
> The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:
>
> ReqCert  ::= CHOICE {
>    certID            CertID,
>    issuerSerial      [0] IssuerandSerialNumber,
>    pKCert            [1] Certificate,
>    name              [2] GeneralName,
>    certHash          [3] OCTET STRING}
>
> CertID          ::=     SEQUENCE {
>    hashAlgorithm       AlgorithmIdentifier,
>    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
>    issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
>    serialNumber        CertificateSerialNumber }
>
> In addition, RFC 2560 includes a serviceLocator request extension, which
> is nice when an OCSP service is supported in the background. However, it
> does not include any extension when a CRL is supported in the background.
> This means that the OCSP server cannot know in general where the CRL to be
> used is located.
>
> :-(
>
> One way would be to send the whole certificate (this is NOT possible with
> RFC 2560) so that the CDP can be extracted by the receiving OCSP
> responder,
> but another possibility would be to use an extension where the CDP
> information present in the certificate would copied and pasted in that
> extension. Then, using issuerSerial, the OCSP responder can
> perform the CRL
> check and to transform it into an OCSP response.
>
> Such extension would look like:
>
> ==================================================================
> =========
> 8.X     CRL Locator
>
> An OCSP server may be operated in a mode whereby the server receives a
> request and fetches the CRL which authoritative for the identified
> certificate. The crlLocator request extension is defined for this
> purpose.
> This extension is included as one of the singleRequestExtensions in
> requests.
>
>    id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }
>
>    CrlLocator ::= CRLDistributionPoints
>
> The value for this field is obtained from the corresponding field in the
> subject certificate.
>
> ==================================================================
> =========
>
> So my proposal would be to issue a new OCSP v2 draft, only
> including these
> two changes. Anything else I forgot ?
>
> Regards,
>
> Denis
>

Date: Thu, 12 Sep 2002 18:43:00 +0200
From: Florian Oelmaier <[email-masked]>
Organization: SyTrust GmbH
To: Denis Pinkas <[email-masked]>
Cc: Stephen Kent <[email-masked]>, Peter Williams <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

> OCSP v2 should NOT expand its possibilities beyond certificate revocation
> checking and certainly should NOT try to expand its capabilities to cover
> certificate validation.

Although this bears some odds from a marketing perspective, I can see 
your arguments and agree to them.

> To be more precise, I do not care about the expired OCSP v2 draft, but I
> care about fixing RFC 2560, while sticking to its original functionality:
> individual certificate revocation information status check.

Agree.

> Having said that, we should correct the major problem that exists in 
> RFC 2560, which is how the certificate can be defined.

[...]

> So my proposal would be to issue a new OCSP v2 draft, only including these 
> two changes. Anything else I forgot ?  

It would be nice to streamline OCSP so that it can be used as some sort 
of "revocation service provider" for one of the upcoming validation 
protocols - I think that is what you all have in mind.

Thus we should add an extension regarding the time of revocation 
checking - to allow the validation protocol to use OCSP while fulfilling 
the DPV-DPD requirements:

"The client can request that the server determine the certificate 
validity at a time other than the current time. The DPV server MUST 
obtain revocation status information for the validation time in the 
client request." - DPV-DPD requirements document

--
Florian Oelmaier
SyTrust

From: "Liaquat Khan" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Peter Williams" <[email-masked]>, <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Thu, 12 Sep 2002 16:02:09 +0500
Importance: Normal
Sender: [email-masked]

Hi,

I think this would be a very useful feature.  A number of PKIs are
hierarchical, and where CRLs are supported at higher levels (for checking
the revocation status of CA certs) and OCSP at lower levels (for checking
the revocation status of end-user certs).  This may be justified for various
reasons.

It should be possible for the OCSP responder to trace the relevant back-end
CRL using the information from the target certificate.  Either the target
certificate should be sent to the OCSP responder in full (so that the CDP
extension can be extracted by the OCSP responder directly) or the relying
party application needs to strip out the CDP extension from the target
certificate and send this in an extension of the OCSP request message as you
mention.

I remember asking for this over a year ago from the authors, and was told
that as OCSPv2 would allow a full certificate to be sent to the OCSP
responder so a special extension would not be needed and I should just wait
for this.  Since then we all know what happend to OCSPv2.

One comment on your post Denis:

>>Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

I was thinking the OCSP responder could also use the serialNumber from the
CertID to do this.

Regards,
LK

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Denis Pinkas
Sent: 12 September 2002 13:48
To: Stephen Kent
Cc: Peter Williams; [email-masked] '
Subject: Re: What happened to the OCSPv2 draft?

Steve,

You said:

"Ambarish later recalled that I warned him about the problems that
extensions to OCSP might engender, and he agreed that they had come
to cause problems."

I do agree we you.

To come back to technical issues, the expired OCSP v2 draft was expanding
its possibilities beyond certificate revocation checking, whereas some
fixing on the deficiencies of RFC 2560 would have been needed, in
particular, as pointed by Peter, more ways to select the certificate to be
checked.

OCSP v2 should NOT expand its possibilities beyond certificate revocation
checking and certainly should NOT try to expand its capabilities to cover
certificate validation.

To be more precise, I do not care about the expired OCSP v2 draft, but I
care about fixing RFC 2560, while sticking to its original functionality:
individual certificate revocation information status check.

Having said that, we should correct the major problem that exists in
RFC 2560, which is how the certificate can be defined.

The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

In addition, RFC 2560 includes a serviceLocator request extension, which
is nice when an OCSP service is supported in the background. However, it
does not include any extension when a CRL is supported in the background.
This means that the OCSP server cannot know in general where the CRL to be
used is located.

:-(

One way would be to send the whole certificate (this is NOT possible with
RFC 2560) so that the CDP can be extracted by the receiving OCSP responder,
but another possibility would be to use an extension where the CDP
information present in the certificate would copied and pasted in that
extension. Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

Such extension would look like:

===========================================================================
8.X     CRL Locator

An OCSP server may be operated in a mode whereby the server receives a
request and fetches the CRL which authoritative for the identified
certificate. The crlLocator request extension is defined for this purpose.
This extension is included as one of the singleRequestExtensions in
requests.

   id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

   CrlLocator ::= CRLDistributionPoints

The value for this field is obtained from the corresponding field in the
subject certificate.

===========================================================================

So my proposal would be to issue a new OCSP v2 draft, only including these
two changes. Anything else I forgot ?

Regards,

Denis

Date: Thu, 12 Sep 2002 10:16:35 -0400
To: "Singer, Ari" <[email-masked]>, "Housley, Russ" <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig natures
Cc: [email-masked]
Sender: [email-masked]

Folks,

The SHA-xxx OIDs identified by Terry are "official" in that they are 
NIST-assigned OIDs from the NIST arc.  These OIDs were assigned based on a 
draft published a few years back, rather than an official NIST publication, 
which is probably why Terry had noted them as provisional.  The OIDs were 
official; the algorithms were not... if the FIPS differed from the draft 
algorithm specification, I intended to issue new OIDs.  (That is also why I 
had not promoted them on the CSOR web pages.)

However, the new secure hash FIPS was issued in August, and the algorithms 
are exactly those defined in the draft specification.   (BTW, the new FIPS 
is available at 
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf).   There is 
no reason to assign new OIDs, so please (continue?) to use the current OIDs:

 > >>     SHA-256:    2.16.840.1.101.3.4.2.1
 > >>     SHA-384:    2.16.840.1.101.3.4.2.2
 > >>     SHA-512:    2.16.840.1.101.3.4.2.3

Clearly, updates to my OID pages are overdue.  I will specify the new SHA 
oids and point to PKCS #1 for the new RSA with SHA-xxx signature algorithm 
oids.  I'm glad to see those have been assigned!

I will also talk to NIST's X9 representatives about  signature OIDs for 
ECDSA with the new hashes, and OIDs for a revised digital signature 
algorithm with larger key sizes (when available).  It doesn't matter to me 
who assigns them; the important thing is that there be just one...   X9 
assigned the previous OIDs, so maybe they'll want to handle these as 
well.  If they can't move quickly enough, I will assign them.  (That 
creates a new problem of course - convincing X9 to specify the NIST oids.)

Thanks,

Tim Polk

At 05:17 PM 9/10/02 -0400, Singer, Ari wrote:

>Hi, Terry and Russ.
>
>This won't answer the question of the "official" source for the SHA-xxx
>OIDs, but I will follow up with Tim to make sure that these are the correct
>OIDs and include them (along with the new RSA OIDs that use them) in the
>next draft of the supplemental algorithms draft as imported OIDs.  That
>should suffice for the PKIX working group, at least.  The new draft will be
>available before the Atlanta meeting.
>
>Best regards,
>Ari
>
>Ari Singer, Principal Engineer
>NTRU
>5 Burlington Woods
>Burlington, MA 01803
>Main: (781) 418-2500
>Personal: (781) 418-2515
>Fax: (781) 418-2532
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[email-masked]]
> > Sent: Tuesday, September 10, 2002 12:52 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> > signatures
> >
> >
> >
> > Terry:
> >
> > It is my understanding from Tim Polk that these OIDs are
> > official.  I do
> > not know the method that will be used to publish them.
> >
> > Russ
> >
> > At 05:25 PM 9/9/2002 -0700, Terry Hayes wrote:
> > >Thanks Russ for the pointers to the new RSA values.  I
> > hadn't noticed the
> > >June update to PKCS #1.
> > >
> > >I see that the latest PKCS #1 update, the lastest S/MIME
> > RSAES-OAEP draft
> > >and the latest PKIX supplimental algorithms draft all refer
> > to the new
> > >hash algorithms using the OIDs that I had seen previously.
> > >
> > >Is there any timetable for an official publication of these
> > OIDs, perhaps
> > >on the CSOR page at NIST
> > >(<http://csrc.nist.gov/csor/algorithms.htm>http://csrc.nist.g
> > ov/csor/algorithms.htm)?
> > >
> > >Terry
> > >
> > >Housley, Russ wrote:
> > >
> > >>Terry:
> > >>
> > >>The most recent PKCS#1 ASN.1 module includes:
> > >>
> > >>    --
> > >>    -- When the following OIDs are used in an
> > AlgorithmIdentifier the
> > >>    -- parameters MUST be present and MUST be NULL.
> > >>    --
> > >>    md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
> > >>    md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
> > >>    sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
> > >>    sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
> > >>    sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
> > >>    sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
> > >>
> > >>
> > >>Russ
> > >>
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: <mailto:[email-masked]>[email-masked]
> > >>To: <mailto:[email-masked]>[email-masked]
> > >>Sent: 9/9/02 6:42 PM
> > >>Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> > >>signatures
> > >>
> > >>Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
> > >>implement them in cryptographic libraries and in protocol
> > >>implementations. However I have not been able to find official
> > >>definitions of the OID values for these new algorithms.
> > >>
> > >>I've seen the following values proposed as the OIDs for the new SHA
> > >>variants:
> > >>
> > >>     SHA-256:    2.16.840.1.101.3.4.2.1
> > >>     SHA-384:    2.16.840.1.101.3.4.2.2
> > >>     SHA-512:    2.16.840.1.101.3.4.2.3
> > >>
> > >>My source for these called these values "provisional."  Is there an
> > >>official definition somewhere?
> > >>
> > >>In addition to OIDs for the hash functions themselves,
> > additional OIDs
> > >>need to be defined for other operations that use them.  In
> > particular, a
> > >>value for sha-256WithRSAEncryption should be defined as soon as
> > >>possible.  I expect that this algorithm will become popular fairly
> > >>quickly, replacing sha-1WithRSAEncryption in deployments
> > that want an
> > >>effective security level of 128 bits.
> > sha-256WithRSAEncryption should
> > >>also be added to the PKIX algorithms RFC (probably as a
> > SHOULD) at the
> > >>next opportunity.
> > >>
> > >>Who will be defining sha-256WithRSAEncryption?
> > >>
> > >>Terry Hayes
> > >><mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>
> >>

Date: Thu, 12 Sep 2002 10:47:49 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: Peter Williams <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Steve,

You said:

"Ambarish later recalled that I warned him about the problems that
extensions to OCSP might engender, and he agreed that they had come 
to cause problems."

I do agree we you.

To come back to technical issues, the expired OCSP v2 draft was expanding
its possibilities beyond certificate revocation checking, whereas some
fixing on the deficiencies of RFC 2560 would have been needed, in
particular, as pointed by Peter, more ways to select the certificate to be
checked.

OCSP v2 should NOT expand its possibilities beyond certificate revocation
checking and certainly should NOT try to expand its capabilities to cover
certificate validation.

To be more precise, I do not care about the expired OCSP v2 draft, but I
care about fixing RFC 2560, while sticking to its original functionality:
individual certificate revocation information status check.

Having said that, we should correct the major problem that exists in 
RFC 2560, which is how the certificate can be defined.

The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}
     
CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

In addition, RFC 2560 includes a serviceLocator request extension, which
is nice when an OCSP service is supported in the background. However, it
does not include any extension when a CRL is supported in the background.
This means that the OCSP server cannot know in general where the CRL to be
used is located. 

:-(

One way would be to send the whole certificate (this is NOT possible with
RFC 2560) so that the CDP can be extracted by the receiving OCSP responder,
but another possibility would be to use an extension where the CDP
information present in the certificate would copied and pasted in that
extension. Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

Such extension would look like:

===========================================================================
8.X     CRL Locator

An OCSP server may be operated in a mode whereby the server receives a
request and fetches the CRL which authoritative for the identified
certificate. The crlLocator request extension is defined for this purpose.  
This extension is included as one of the singleRequestExtensions in
requests.

   id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

   CrlLocator ::= CRLDistributionPoints
 
The value for this field is obtained from the corresponding field in the 
subject certificate.

===========================================================================

So my proposal would be to issue a new OCSP v2 draft, only including these 
two changes. Anything else I forgot ?  

Regards,

Denis

From: "Michael Myers" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 19:44:52 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Denis Pinkas
> Sent: Wednesday, September 11, 2002 8:44 AM
> 
> I do not care about OCSP v2: some documents die.

I agree.  Drafts expire.  Needs do not.

Mike

Date: Wed, 11 Sep 2002 18:23:48 -0400
To: "Hallam-Baker, Phillip" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: [email-masked]
Sender: [email-masked]

At 3:04 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > Extensions can dramatically alter the semantics, functionality, and
>>  security of a base protocol or data structure.
>
>Agreed, that is why I don't want random extensions that do not have
>vendor or developer support to be accorded the same status as the
>PKIX profile that does have vendor and developer support.

I think we basically agree, expect that I would phrase it in terms of 
having the same WG approve the extensions as approved the original 
document.

>
>
>>  Todd's most recent effort was directed at removing me as chair of the
>>  PKIX WG, by persuading someone to take my place, or create a new WG
>>  for which I was not the chair, or to persuade the IESG or IAB that
>>  PKIX was broken and needed to be fixed, and then, ultimately, to
>>  convince the IAB & IESG that the IETF was broken and needed to be
>>  fixed.
>
>And you foiled the plot by putting a fake timestamp on the moment
>at which the IESG and IAB were convinced?

I have no comment on that heinous accusation at this time, or at that 
other time, whenever it was, or may yet be, or ....

Steve

Date: Wed, 11 Sep 2002 18:33:13 -0400
To: Peter Williams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

At 3:16 PM -0700 9/11/02, Peter Williams wrote:
>
>Extensions can alter the semantics of a security protocol. In
>IETF we allow private organizations to create new extensions
>for both certificates and OCSP, note. We know that cert politcy
>qualifiers alter the impact of using (not processing) cert
>chains dramatically, for example, as intended by ISO.

Well, I think we all agree that vendor-specified extensions to these 
protocols or data structures can cause trouble, and thus I personally 
am not a fan of such things. Ambarish later recalled that I warned 
him about the problems that extensions to OCSP might engender, and he 
agreed that they had come to cause problems.

>Its not sensible to argue that WG-ratified extensions have
>to be controlled (against unwarranted changes to PKIX semantics)
>whilst we allow others to perform independently peform such
>change of semantics. If we are to accept Steve's logic, we should
>alter OCSP to require (non-experimental) extension registration,
>with IANA, to preseve IETF process input. Registered Extensions
>would have to through a WG process then, logically PKIX  - while
>PKIX WG exists.

Extensions that do not carry the imprimatur of a standards body often 
see less widespread deployment (depending on the vendor, of course) 
and thus pose less of a risk than extensions that are approved by a 
standards body. So, on that basis I do think it appropriate to try to 
maintain WG control over extensions to the extent possible.

And yes, I would prefer extensions to be approved by a WG (PKIX in 
this case) before being assigned an OID bu IANA.  Other WGs have 
adopted that tactic for registration for analogous values.

>
>OCSP has no significant IETF-defined compliance rules, note.

Yor are right. We could have done better.

>-----
>
>I think another valid question is, what do we do with the
>SCVP id. Authors?

I don't think the WG gets to do anything to authors in general :-). 
And, I'm sorry, but I lost track here. I thought we were discussing 
OCSPv2, not SCVP. If someone, you for example, want to assume 
responsibility for OCSPv2, and if the WG is convinced that there is 
good reason to publish a new version, e.g., to fix some problems with 
the old version that require a versin # change, then we can proceed.

Steve

Steve

Content-return: allowed
Date: Wed, 11 Sep 2002 15:16:00 -0700
From: Peter Williams <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
To: "'Stephen Kent '" <[email-masked]>
Cc: "'Hallam-Baker, Phillip '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.

--Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)
Content-type: text/plain

Extensions can alter the semantics of a security protocol. In 
IETF we allow private organizations to create new extensions
for both certificates and OCSP, note. We know that cert politcy
qualifiers alter the impact of using (not processing) cert 
chains dramatically, for example, as intended by ISO.

Its not sensible to argue that WG-ratified extensions have
to be controlled (against unwarranted changes to PKIX semantics)
whilst we allow others to perform independently peform such
change of semantics. If we are to accept Steve's logic, we should
alter OCSP to require (non-experimental) extension registration, 
with IANA, to preseve IETF process input. Registered Extensions 
would have to through a WG process then, logically PKIX  - while
PKIX WG exists.

OCSP has no significant IETF-defined compliance rules, note.

-----

I think another valid question is, what do we do with the
SCVP id. Authors?

Peter.

-----Original Message-----
From: Stephen Kent
To: Hallam-Baker, Phillip
Cc: Hallam-Baker, Phillip; [email-masked]
Sent: 9/11/02 2:30 PM
Subject: RE: What happened to the OCSPv2 draft?

At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > By my count, that's two messages in a row from you on the theme of
>>  "let's kill off the PKIX WG."
>
>Congratulations, you spotted the hiddern pattern. Actually the wrong
>one. I have been arguing that the group should split off an extensions
>group and close the main group once all the milestones are complete.

Extensions can dramatically alter the semantics, functionality, and 
security of a base protocol or data structure. So I don't see the 
justification for having a different WG deal with extensions to 
previously developed PKIX standards. If one believed that was an 
appropriate path, then we should have changed WGs going from v1 
certs, to v2 certs, to v3 certs ...

>  > The future of OCSPv2 and its relevance to to the question of the
>>  future of this WG is equally silly.
>
>Why is it silly to ask whether the group should continue to progress
>a draft when the authors and much of the audience appear to have lost
>interest?

I didn't suggest that what you said above was a silly question. I 
suggested it was silly to use the question of extensions to OCSP as a 
basis for creating a new WG, consistent with my comments above. I 
agree with your question, i.e., unless there are supporters for an 
ID, it will not progress. If the authors loose interest then other 
authors have to take over, or the ID dies.  No disagreement there.

>  > Have you been hanging out with Todd?
>
>I was under the impression that Todd was arguing to take on more work
>rather than the reverse.

Todd's most recent effort was directed at removing me as chair of the 
PKIX WG, by persuading someone to take my place, or create a new WG 
for which I was not the chair, or to persuade the IESG or IAB that 
PKIX was broken and needed to be fixed, and then, ultimately, to 
convince the IAB & IESG that the IETF was broken and needed to be 
fixed.

Steve

--Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)
Content-type: text/html

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

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>Extensions can alter the semantics of a security protocol. In </FONT>
<BR><FONT SIZE=2>IETF we allow private organizations to create new extensions</FONT>
<BR><FONT SIZE=2>for both certificates and OCSP, note. We know that cert politcy</FONT>
<BR><FONT SIZE=2>qualifiers alter the impact of using (not processing) cert </FONT>
<BR><FONT SIZE=2>chains dramatically, for example, as intended by ISO.</FONT>
</P>

<P><FONT SIZE=2>Its not sensible to argue that WG-ratified extensions have</FONT>
<BR><FONT SIZE=2>to be controlled (against unwarranted changes to PKIX semantics)</FONT>
<BR><FONT SIZE=2>whilst we allow others to perform independently peform such</FONT>
<BR><FONT SIZE=2>change of semantics. If we are to accept Steve's logic, we should</FONT>
<BR><FONT SIZE=2>alter OCSP to require (non-experimental) extension registration, </FONT>
<BR><FONT SIZE=2>with IANA, to preseve IETF process input. Registered Extensions </FONT>
<BR><FONT SIZE=2>would have to through a WG process then, logically PKIX&nbsp; - while</FONT>
<BR><FONT SIZE=2>PKIX WG exists.</FONT>
</P>

<P><FONT SIZE=2>OCSP has no significant IETF-defined compliance rules, note.</FONT>
</P>

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

<P><FONT SIZE=2>I think another valid question is, what do we do with the</FONT>
<BR><FONT SIZE=2>SCVP id. Authors?</FONT>
</P>

<P><FONT SIZE=2>Peter.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Stephen Kent</FONT>
<BR><FONT SIZE=2>To: Hallam-Baker, Phillip</FONT>
<BR><FONT SIZE=2>Cc: Hallam-Baker, Phillip; [email-masked]</FONT>
<BR><FONT SIZE=2>Sent: 9/11/02 2:30 PM</FONT>
<BR><FONT SIZE=2>Subject: RE: What happened to the OCSPv2 draft?</FONT>
</P>
<BR>

<P><FONT SIZE=2>At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; &gt; By my count, that's two messages in a row from you on the theme of</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp; &quot;let's kill off the PKIX WG.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Congratulations, you spotted the hiddern pattern. Actually the wrong</FONT>
<BR><FONT SIZE=2>&gt;one. I have been arguing that the group should split off an extensions</FONT>
<BR><FONT SIZE=2>&gt;group and close the main group once all the milestones are complete.</FONT>
</P>

<P><FONT SIZE=2>Extensions can dramatically alter the semantics, functionality, and </FONT>
<BR><FONT SIZE=2>security of a base protocol or data structure. So I don't see the </FONT>
<BR><FONT SIZE=2>justification for having a different WG deal with extensions to </FONT>
<BR><FONT SIZE=2>previously developed PKIX standards. If one believed that was an </FONT>
<BR><FONT SIZE=2>appropriate path, then we should have changed WGs going from v1 </FONT>
<BR><FONT SIZE=2>certs, to v2 certs, to v3 certs ...</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt;&nbsp; &gt; The future of OCSPv2 and its relevance to to the question of the</FONT>
<BR><FONT SIZE=2>&gt;&gt;&nbsp; future of this WG is equally silly.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;Why is it silly to ask whether the group should continue to progress</FONT>
<BR><FONT SIZE=2>&gt;a draft when the authors and much of the audience appear to have lost</FONT>
<BR><FONT SIZE=2>&gt;interest?</FONT>
</P>

<P><FONT SIZE=2>I didn't suggest that what you said above was a silly question. I </FONT>
<BR><FONT SIZE=2>suggested it was silly to use the question of extensions to OCSP as a </FONT>
<BR><FONT SIZE=2>basis for creating a new WG, consistent with my comments above. I </FONT>
<BR><FONT SIZE=2>agree with your question, i.e., unless there are supporters for an </FONT>
<BR><FONT SIZE=2>ID, it will not progress. If the authors loose interest then other </FONT>
<BR><FONT SIZE=2>authors have to take over, or the ID dies.&nbsp; No disagreement there.</FONT>
</P>

<P><FONT SIZE=2>&gt;&nbsp; &gt; Have you been hanging out with Todd?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I was under the impression that Todd was arguing to take on more work</FONT>
<BR><FONT SIZE=2>&gt;rather than the reverse.</FONT>
</P>

<P><FONT SIZE=2>Todd's most recent effort was directed at removing me as chair of the </FONT>
<BR><FONT SIZE=2>PKIX WG, by persuading someone to take my place, or create a new WG </FONT>
<BR><FONT SIZE=2>for which I was not the chair, or to persuade the IESG or IAB that </FONT>
<BR><FONT SIZE=2>PKIX was broken and needed to be fixed, and then, ultimately, to </FONT>
<BR><FONT SIZE=2>convince the IAB &amp; IESG that the IETF was broken and needed to be </FONT>
<BR><FONT SIZE=2>fixed.</FONT>
</P>

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

</BODY>
</HTML>

--Boundary_(ID_cW0Gsl5TbKkX8HKoVr9iuw)--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: "Hallam-Baker, Phillip" <[email-masked]>, [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 15:04:05 -0700
Sender: [email-masked]

> Extensions can dramatically alter the semantics, functionality, and 
> security of a base protocol or data structure.

Agreed, that is why I don't want random extensions that do not have
vendor or developer support to be accorded the same status as the 
PKIX profile that does have vendor and developer support.

> Todd's most recent effort was directed at removing me as chair of the 
> PKIX WG, by persuading someone to take my place, or create a new WG 
> for which I was not the chair, or to persuade the IESG or IAB that 
> PKIX was broken and needed to be fixed, and then, ultimately, to 
> convince the IAB & IESG that the IETF was broken and needed to be 
> fixed.

And you foiled the plot by putting a fake timestamp on the moment 
at which the IESG and IAB were convinced?

		Phill

Date: Wed, 11 Sep 2002 17:30:23 -0400
To: "Hallam-Baker, Phillip" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: "Hallam-Baker, Phillip"	 <[email-masked]>, [email-masked]
Sender: [email-masked]

At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > By my count, that's two messages in a row from you on the theme of
>>  "let's kill off the PKIX WG."
>
>Congratulations, you spotted the hiddern pattern. Actually the wrong
>one. I have been arguing that the group should split off an extensions
>group and close the main group once all the milestones are complete.

Extensions can dramatically alter the semantics, functionality, and 
security of a base protocol or data structure. So I don't see the 
justification for having a different WG deal with extensions to 
previously developed PKIX standards. If one believed that was an 
appropriate path, then we should have changed WGs going from v1 
certs, to v2 certs, to v3 certs ...

>  > The future of OCSPv2 and its relevance to to the question of the
>>  future of this WG is equally silly.
>
>Why is it silly to ask whether the group should continue to progress
>a draft when the authors and much of the audience appear to have lost
>interest?

I didn't suggest that what you said above was a silly question. I 
suggested it was silly to use the question of extensions to OCSP as a 
basis for creating a new WG, consistent with my comments above. I 
agree with your question, i.e., unless there are supporters for an 
ID, it will not progress. If the authors loose interest then other 
authors have to take over, or the ID dies.  No disagreement there.

>  > Have you been hanging out with Todd?
>
>I was under the impression that Todd was arguing to take on more work
>rather than the reverse.

Todd's most recent effort was directed at removing me as chair of the 
PKIX WG, by persuading someone to take my place, or create a new WG 
for which I was not the chair, or to persuade the IESG or IAB that 
PKIX was broken and needed to be fixed, and then, ultimately, to 
convince the IAB & IESG that the IETF was broken and needed to be 
fixed.

Steve

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 13:27:25 -0700
Sender: [email-masked]

> By my count, that's two messages in a row from you on the theme of 
> "let's kill off the PKIX WG." 

Congratulations, you spotted the hiddern pattern. Actually the wrong 
one. I have been arguing that the group should split off an extensions 
group and close the main group once all the milestones are complete.

> The future of OCSPv2 and its relevance to to the question of the 
> future of this WG is equally silly.

Why is it silly to ask whether the group should continue to progress
a draft when the authors and much of the audience appear to have lost
interest?

> Have you been hanging out with Todd?

I was under the impression that Todd was arguing to take on more work
rather than the reverse.

		Phill

Date: Wed, 11 Sep 2002 14:55:01 -0400
To: "Hallam-Baker, Phillip" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: What happened to the OCSPv2 draft?
Cc: [email-masked]
Sender: [email-masked]

At 11:25 AM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>The premise of the original OCSP redesign was to make it extensible.
>Ambarish was the main advocate of the modifications.
>
>Now that people are saying that extending OCSP is not the way to support
>related certificate status and validity type functions and Ambarish has
>proposed creating yet another protocol. Those of us who had the extension
>mechanism forced on us have the right to form a judgement on the matter.
>
>This type of thing is only one example of the sort of never-ending tinkering
>that will happen if a group continues after all its milestones have been
>achieved. It is time for this group to declare victory and close. I do not
>believe that further work in this forum is going to result in any
>improvement of the drafts and is most likely to make things worse.
>
>Give the authors of the various drafts a couple of months to get the best
>efforts in and then have a humm poll at the spring IETF on which ones
>crossed the line in terms of being acceptably complete. Anything that fails
>to meet the deadline has to persuade the IESG to let them form a new working
>group or submit the idea as an X.509 defect report.
>
>		Phill
>

By my count, that's two messages in a row from you on the theme of 
"let's kill off the PKIX WG."  Your first message claimed that we are 
pursuing standardization of any protocol that uses ASN.1. All the 
work we have pursued is PKI-based, including the warranty extension, 
DPV/DPD, proxy certs, time stamp policies, etc.  So, that comment is 
patently false.

The future of OCSPv2 and its relevance to to the question of the 
future of this WG is equally silly.

Have you been hanging out with Todd?

Steve

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: What happened to the OCSPv2 draft?
Date: Wed, 11 Sep 2002 11:25:40 -0700
Sender: [email-masked]

The premise of the original OCSP redesign was to make it extensible.
Ambarish was the main advocate of the modifications.

Now that people are saying that extending OCSP is not the way to support
related certificate status and validity type functions and Ambarish has
proposed creating yet another protocol. Those of us who had the extension
mechanism forced on us have the right to form a judgement on the matter.

This type of thing is only one example of the sort of never-ending tinkering
that will happen if a group continues after all its milestones have been
achieved. It is time for this group to declare victory and close. I do not
believe that further work in this forum is going to result in any
improvement of the drafts and is most likely to make things worse.

Give the authors of the various drafts a couple of months to get the best
efforts in and then have a humm poll at the spring IETF on which ones
crossed the line in terms of being acceptably complete. Anything that fails
to meet the deadline has to persuade the IESG to let them form a new working
group or submit the idea as an X.509 defect report.

		Phill 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 8:09 AM
> To: [email-masked]
> Subject: What happened to the OCSPv2 draft?
> 
> 
> 
> This seems to have died at -02, there are hints of a -03 but 
> no copies remain,
> and the -02 draft is 1 1/2 years old.
> 
> (The reason I'd like to get a later version is that the -02 
> draft mixes up
>  explicit and implicit tagging, and I'd like to see whether a 
> newer version
>  includes an ASN.1 module which clarifies what's actually 
> being used.  The
>  -02 draft doesn't).
> 
> Peter.
> 

Date: Wed, 11 Sep 2002 17:43:44 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: What happened to the OCSPv2 draft?
Sender: [email-masked]

Peter,

I do not care about OCSP v2: some documents die.

However, I care with OCSP(v1)bis. The Yokohama meeting report states:

"Roadmap, OCSP(v1)bis and PI documents in IESG queue."

The document is available at: http://www.imc.org/draft-ietf-pkix-rfc2560bis

Maybe you have the answer to your question in that document ?

Denis

> This seems to have died at -02, there are hints of a -03 but no copies remain,
> and the -02 draft is 1 1/2 years old.
> 
> (The reason I'd like to get a later version is that the -02 draft mixes up
>  explicit and implicit tagging, and I'd like to see whether a newer version
>  includes an ASN.1 module which clarifies what's actually being used.  The
>  -02 draft doesn't).
> 
> Peter.

Date: Thu, 12 Sep 2002 03:09:22 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: What happened to the OCSPv2 draft?
Sender: [email-masked]

This seems to have died at -02, there are hints of a -03 but no copies remain,
and the -02 draft is 1 1/2 years old.

(The reason I'd like to get a later version is that the -02 draft mixes up
 explicit and implicit tagging, and I'd like to see whether a newer version
 includes an ASN.1 module which clarifies what's actually being used.  The
 -02 draft doesn't).

Peter.

From: "Singer, Ari" <[email-masked]>
To: "Housley, Russ" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig natures
Date: Tue, 10 Sep 2002 17:17:24 -0400
Sender: [email-masked]

Hi, Terry and Russ.

This won't answer the question of the "official" source for the SHA-xxx
OIDs, but I will follow up with Tim to make sure that these are the correct
OIDs and include them (along with the new RSA OIDs that use them) in the
next draft of the supplemental algorithms draft as imported OIDs.  That
should suffice for the PKIX working group, at least.  The new draft will be
available before the Atlanta meeting.

Best regards,
Ari

Ari Singer, Principal Engineer
NTRU
5 Burlington Woods
Burlington, MA 01803
Main: (781) 418-2500
Personal: (781) 418-2515
Fax: (781) 418-2532

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 12:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> signatures
> 
> 
> 
> Terry:
> 
> It is my understanding from Tim Polk that these OIDs are 
> official.  I do 
> not know the method that will be used to publish them.
> 
> Russ
> 
> At 05:25 PM 9/9/2002 -0700, Terry Hayes wrote:
> >Thanks Russ for the pointers to the new RSA values.  I 
> hadn't noticed the 
> >June update to PKCS #1.
> >
> >I see that the latest PKCS #1 update, the lastest S/MIME 
> RSAES-OAEP draft 
> >and the latest PKIX supplimental algorithms draft all refer 
> to the new 
> >hash algorithms using the OIDs that I had seen previously.
> >
> >Is there any timetable for an official publication of these 
> OIDs, perhaps 
> >on the CSOR page at NIST 
> >(<http://csrc.nist.gov/csor/algorithms.htm>http://csrc.nist.g
> ov/csor/algorithms.htm)?
> >
> >Terry
> >
> >Housley, Russ wrote:
> >
> >>Terry:
> >>
> >>The most recent PKCS#1 ASN.1 module includes:
> >>
> >>    --
> >>    -- When the following OIDs are used in an 
> AlgorithmIdentifier the
> >>    -- parameters MUST be present and MUST be NULL.
> >>    --
> >>    md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
> >>    md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
> >>    sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
> >>    sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
> >>    sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
> >>    sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
> >>
> >>
> >>Russ
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: <mailto:[email-masked]>[email-masked]
> >>To: <mailto:[email-masked]>[email-masked]
> >>Sent: 9/9/02 6:42 PM
> >>Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
> >>signatures
> >>
> >>Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
> >>implement them in cryptographic libraries and in protocol
> >>implementations. However I have not been able to find official
> >>definitions of the OID values for these new algorithms.
> >>
> >>I've seen the following values proposed as the OIDs for the new SHA
> >>variants:
> >>
> >>     SHA-256:    2.16.840.1.101.3.4.2.1
> >>     SHA-384:    2.16.840.1.101.3.4.2.2
> >>     SHA-512:    2.16.840.1.101.3.4.2.3
> >>
> >>My source for these called these values "provisional."  Is there an
> >>official definition somewhere?
> >>
> >>In addition to OIDs for the hash functions themselves, 
> additional OIDs
> >>need to be defined for other operations that use them.  In 
> particular, a
> >>value for sha-256WithRSAEncryption should be defined as soon as
> >>possible.  I expect that this algorithm will become popular fairly
> >>quickly, replacing sha-1WithRSAEncryption in deployments 
> that want an
> >>effective security level of 128 bits.  
> sha-256WithRSAEncryption should
> >>also be added to the PKIX algorithms RFC (probably as a 
> SHOULD) at the
> >>next opportunity.
> >>
> >>Who will be defining sha-256WithRSAEncryption?
> >>
> >>Terry Hayes
> >><mailto:[email-masked]>[email-masked] 
<mailto:[email-masked]>

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 10 Sep 2002 12:52:15 -0400
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated signatures
Sender: [email-masked]

Terry:

It is my understanding from Tim Polk that these OIDs are official.  I do 
not know the method that will be used to publish them.

Russ

At 05:25 PM 9/9/2002 -0700, Terry Hayes wrote:
>Thanks Russ for the pointers to the new RSA values.  I hadn't noticed the 
>June update to PKCS #1.
>
>I see that the latest PKCS #1 update, the lastest S/MIME RSAES-OAEP draft 
>and the latest PKIX supplimental algorithms draft all refer to the new 
>hash algorithms using the OIDs that I had seen previously.
>
>Is there any timetable for an official publication of these OIDs, perhaps 
>on the CSOR page at NIST 
>(<http://csrc.nist.gov/csor/algorithms.htm>http://csrc.nist.gov/csor/algorithms.htm)?
>
>Terry
>
>Housley, Russ wrote:
>
>>Terry:
>>
>>The most recent PKCS#1 ASN.1 module includes:
>>
>>    --
>>    -- When the following OIDs are used in an AlgorithmIdentifier the
>>    -- parameters MUST be present and MUST be NULL.
>>    --
>>    md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
>>    md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
>>    sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
>>    sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
>>    sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
>>    sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }
>>
>>
>>Russ
>>
>>
>>
>>-----Original Message-----
>>From: <mailto:[email-masked]>[email-masked]
>>To: <mailto:[email-masked]>[email-masked]
>>Sent: 9/9/02 6:42 PM
>>Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
>>signatures
>>
>>Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
>>implement them in cryptographic libraries and in protocol
>>implementations. However I have not been able to find official
>>definitions of the OID values for these new algorithms.
>>
>>I've seen the following values proposed as the OIDs for the new SHA
>>variants:
>>
>>     SHA-256:    2.16.840.1.101.3.4.2.1
>>     SHA-384:    2.16.840.1.101.3.4.2.2
>>     SHA-512:    2.16.840.1.101.3.4.2.3
>>
>>My source for these called these values "provisional."  Is there an
>>official definition somewhere?
>>
>>In addition to OIDs for the hash functions themselves, additional OIDs
>>need to be defined for other operations that use them.  In particular, a
>>value for sha-256WithRSAEncryption should be defined as soon as
>>possible.  I expect that this algorithm will become popular fairly
>>quickly, replacing sha-1WithRSAEncryption in deployments that want an
>>effective security level of 128 bits.  sha-256WithRSAEncryption should
>>also be added to the PKIX algorithms RFC (probably as a SHOULD) at the
>>next opportunity.
>>
>>Who will be defining sha-256WithRSAEncryption?
>>
>>Terry Hayes
>><mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>

Date: Tue, 10 Sep 2002 10:00:23 -0500
From: Matt Crawford <[email-masked]>
Subject: OID for a Kerberos principal name in an X509 subject DN?
To: [email-masked], [email-masked]
Sender: [email-masked]

Is there a correct OID to use for including a Kerberos principal name
in a DN?  Is it one of

	1.2.840.113554.1.2.2.1 - gss-krb5-nt-principal-name
		(...mit infosys gssapi krb5 krb5_name)
or
	1.3.6.1.5.6.4 - gss-api-exported-name

or something completely different?

Date: Tue, 10 Sep 2002 02:52:28 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated signatures
Sender: [email-masked]

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

Terry Hayes wrote:
> Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
> implement them in cryptographic libraries and in protocol implementations.
> However I have not been able to find official definitions of the OID values
> for these new algorithms.
> 
> I've seen the following values proposed as the OIDs for the new SHA variants:
> 
>     SHA-256:    2.16.840.1.101.3.4.2.1
>     SHA-384:    2.16.840.1.101.3.4.2.2
>     SHA-512:    2.16.840.1.101.3.4.2.3
> 
> My source for these called these values "provisional."

That was probably me (see <http://www.users.zetnet.co.uk/hopwood/crypto/scan/>),
so I should say where I got those OIDs from. They come from two sources that
agree with each other:

 - decoding the DER given in the description of the EMSA3 encoding method in
   P1363a (since at least draft 7, I believe, but certainly in section 12.1.3
   of draft 10.5).

 - PKCS#1 v2.1 draft 2, section B.1, which says:

     id-SHA256 OBJECT IDENTIFIER ::=
       {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)
        nistalgorithm(4) hashalgs(2) 1 }

     id-SHA384 OBJECT IDENTIFIER ::=
       {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)
        nistalgorithm(4) hashalgs(2) 2 }

     id-SHA512 OBJECT IDENTIFIER ::=
       {joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3)
        nistalgorithm(4) hashalgs(2) 3 }

They *should* also be documented at <http://csrc.nist.gov/csor/algorithms.htm>,
but aren't. I got no response the last time I emailed NIST about this, although
that was some time ago.

The OIDs for the hash functions are of course different from the OIDs for the
corresponding RSA signature schemes, which are what Russ Housley posted.

The Google search <http://www.google.com/search?q=2.16.840.1.101.3.4.2.1>
seems to imply that some people have already been including these OIDs in
libraries and protocol drafts (e.g. the OpenPGP / RFC2440bis draft).

- -- 
David Hopwood <[email-masked]>

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

Date: Mon, 9 Sep 2002 17:25:19 -0700
From: [email-masked] (Terry Hayes)
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig	natures
To: [email-masked], Russ <[email-masked]>
cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Organization: Netscape Communications Corp.
Sender: [email-masked]

Thanks Russ for the pointers to the new RSA values. =A0I hadn't noticed the
June update to PKCS #1.<br>
<br>
I see that the latest PKCS #1 update, the lastest S/MIME RSAES-OAEP draft
and the latest PKIX supplimental algorithms draft all refer to the new hash
algorithms using the OIDs that I had seen previously.<br>
<br>
Is there any timetable for an official publication of these OIDs, perhaps
on the CSOR page at NIST (<a class=3D"moz-txt-link-freetext" href=3D"http:/=
/csrc.nist.gov/csor/algorithms.htm">http://csrc.nist.gov/csor/algorithms.ht=
m</a>)?<br>
<br>
Terry<br>
<br>
Housley, Russ wrote:<br>
=20
<p> </p>
<blockquote type=3D"cite"
 style=3D"border-left: thin solid blue; padding-left: 10px; margin-left: 0p=
t;">=20
  <tt> Terry: <br>
 <br>
 The most recent PKCS#1 ASN.1 module includes: <br>
 <br>
 =A0=A0 -- <br>
 =A0=A0 -- When the following OIDs are used in an AlgorithmIdentifier the <=
br>
 =A0=A0 -- parameters MUST be present and MUST be NULL. <br>
 =A0=A0 -- <br>
 =A0=A0 md2WithRSAEncryption=A0=A0=A0=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pk=
cs-1 2 } <br>
 =A0=A0 md5WithRSAEncryption=A0=A0=A0=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pk=
cs-1 4 } <br>
 =A0=A0 sha1WithRSAEncryption=A0=A0=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs=
-1 5 } <br>
 =A0=A0 sha256WithRSAEncryption=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs-1 1=
1 } <br>
 =A0=A0 sha384WithRSAEncryption=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs-1 1=
2 } <br>
 =A0=A0 sha512WithRSAEncryption=A0=A0=A0 OBJECT IDENTIFIER ::=3D { pkcs-1 1=
3 } <br>
 =A0=A0 <br>
 <br>
 Russ <br>
 <br>
  <br>
 <br>
 -----Original Message----- <br>
 From: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:thayes@netscape=
.com">[email-masked]</a> <br>
 To: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]=
">[email-masked]</a> <br>
 Sent: 9/9/02 6:42 PM <br>
 Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated <br>
 signatures <br>
 <br>
 Now that FIPS 180-2 will be effective in Feburary 2003, it's time to <br>
 implement them in cryptographic libraries and in protocol <br>
 implementations. However I have not been able to find official <br>
 definitions of the OID values for these new algorithms. <br>
 <br>
 I've seen the following values proposed as the OIDs for the new SHA <br>
 variants: <br>
 <br>
 =A0=A0=A0 SHA-256:=A0=A0=A0 2.16.840.1.101.3.4.2.1 <br>
 =A0=A0=A0 SHA-384:=A0=A0=A0 2.16.840.1.101.3.4.2.2 <br>
 =A0=A0=A0 SHA-512:=A0=A0=A0 2.16.840.1.101.3.4.2.3 <br>
 <br>
 My source for these called these values "provisional."=A0 Is there an <br>
 official definition somewhere? <br>
 <br>
 In addition to OIDs for the hash functions themselves, additional OIDs <br=
 need to be defined for other operations that use them.=A0 In particular, a=
=20
  <br>
 value for sha-256WithRSAEncryption should be defined as soon as <br>
 possible.=A0 I expect that this algorithm will become popular fairly <br>
 quickly, replacing sha-1WithRSAEncryption in deployments that want an <br>
 effective security level of 128 bits.=A0 sha-256WithRSAEncryption should <=
br>
 also be added to the PKIX algorithms RFC (probably as a SHOULD) at the <br=
 next opportunity. <br>
 <br>
 Who will be defining sha-256WithRSAEncryption? <br>
 <br>
 Terry Hayes <br>
 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">=
[email-masked]</a> &lt;<a href=3D"mailto:[email-masked]">mailto:t=
[email-masked]</a>&gt;
  <br>
 <br>
 <br>
 </tt> </blockquote>

From: "Housley, Russ" <[email-masked]>
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated sig natures
Date: Mon, 9 Sep 2002 19:29:27 -0400 
Sender: [email-masked]

Terry:

The most recent PKCS#1 ASN.1 module includes:

   --
   -- When the following OIDs are used in an AlgorithmIdentifier the
   -- parameters MUST be present and MUST be NULL.
   --
   md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
   md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
   sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
   sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
   sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
   sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }

Russ

-----Original Message-----
From: [email-masked]
To: [email-masked]
Sent: 9/9/02 6:42 PM
Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated
signatures

Now that FIPS 180-2 will be effective in Feburary 2003, it's time to
implement them in cryptographic libraries and in protocol
implementations. However I have not been able to find official
definitions of the OID values for these new algorithms.

I've seen the following values proposed as the OIDs for the new SHA
variants:

    SHA-256:    2.16.840.1.101.3.4.2.1
    SHA-384:    2.16.840.1.101.3.4.2.2
    SHA-512:    2.16.840.1.101.3.4.2.3

My source for these called these values "provisional."  Is there an
official definition somewhere?

In addition to OIDs for the hash functions themselves, additional OIDs
need to be defined for other operations that use them.  In particular, a
value for sha-256WithRSAEncryption should be defined as soon as
possible.  I expect that this algorithm will become popular fairly
quickly, replacing sha-1WithRSAEncryption in deployments that want an
effective security level of 128 bits.  sha-256WithRSAEncryption should
also be added to the PKIX algorithms RFC (probably as a SHOULD) at the
next opportunity.

Who will be defining sha-256WithRSAEncryption?

Terry Hayes
[email-masked] <mailto:[email-masked]> 

Date: Mon, 9 Sep 2002 15:42:43 -0700
From: [email-masked] (Terry Hayes)
Subject: Algorithm OIDs for SHA-256, SHA-384, SHA-512 and releated signatures
To: [email-masked]
Organization: Netscape Communications Corp.
Sender: [email-masked]

Now that FIPS 180-2 will be effective in Feburary 2003, it's time to implem=
ent
them in cryptographic libraries and in protocol implementations. However
I have not been able to find official definitions of the OID values for the=
se
new algorithms.<br>
<br>
I've seen the following values proposed as the OIDs for the new SHA variant=
s:<br>
<br>
=A0=A0=A0 SHA-256:=A0=A0=A0 2.16.840.1.101.3.4.2.1<br>
=A0=A0=A0 SHA-384:=A0=A0=A0 2.16.840.1.101.3.4.2.2<br>
=A0=A0=A0 SHA-512:=A0=A0=A0 2.16.840.1.101.3.4.2.3<br>
<br>
My source for these called these values "provisional." =A0Is there an offic=
ial
definition somewhere?<br>
<br>
In addition to OIDs for the hash functions themselves, additional OIDs need
to be defined for other operations that use them. =A0In particular, a value
for sha-256WithRSAEncryption should be defined as soon as possible. =A0I ex=
pect
that this algorithm will become popular fairly quickly, replacing sha-1With=
RSAEncryption
in deployments that want an effective security level of 128 bits. =A0sha-25=
6WithRSAEncryption
should also be added to the PKIX algorithms RFC (probably as a SHOULD) at
the next opportunity.<br>
<br>
Who will be defining sha-256WithRSAEncryption?<br>
<br>
Terry Hayes<br>
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">t=
[email-masked]</a><br>
<br>

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Steve Tuecke <[email-masked]>
Cc: [email-masked]
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
Date: Mon, 9 Sep 2002 11:41:05 -0700 
Sender: [email-masked]

Answer: Start a new group

PKIX was formed to do one thing and has become a standing committee that
will do anything, provided it is in ASN.1 syntax. That is a bad thing. 

I would much prefer to see the group split into two. Continuing PKIX would
be tasked with simply moving the current RFCs through the standards track to
Draft and Standard. PKIX-EXT would be tasked with developing extensions to
PKIX where necessary.

		Phill 

Content-return: allowed
Date: Mon, 09 Sep 2002 11:23:57 -0700
From: Peter Williams <[email-masked]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
To: "'Denis Pinkas '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Cc: "'Anders Rundgren '" <[email-masked]>, "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.

--Boundary_(ID_5b881ouBlaerftQXl7K/Sg)
Content-type: text/plain

I helped review the first warranty program, for Michael
Baum's Public Certification Service concept. Whilst I dont 
believe its useful for IETF to focus on
warranties, I do believe clarifiation of just
what a CP-based warranty is is useful.

I dont expect users to ever really understand the
difference in the legal model between certification, 
representation, warranty, insurance, reliance, etc.

What they do need to understand however is

1. The common notion of first-come-first-served 
payout-limits (which means they may get a shock when multiple 
parties all claim for the limited cash)

2. Warranty execlusions are often structured such that
few can ever make a valid claim. These warranties
are just marketing gimics, to puff trustworthiness.
Valuable warranties are transactional, by banks or
Japanese trading houses like Mitsui. They really
dont function as an adjunt to authentication.

Conclusion: If IETF proceeds, the result should be at most
an informational RFC.

N.B.

My comments - as a practitioner - may sound harsh on public 
CAs. Warranties are appropriate - they just dont have in practice 
the direct  benefits that are marketed. The costs of the 
protection plans' insurance is essentially just 
an indirect tax on providing core trustworthiness of
a TTP-grade CA.

-----Original Message-----
From: Denis Pinkas
To: [email-masked]
Cc: Anders Rundgren; [email-masked]; [email-masked]
Sent: 9/2/02 3:50 AM
Subject: Re: draft-ietf-pkix-warranty-ext-01

Alice,

I concur with many of the arguments raised by Anders. It is very scarce,
but
this time it happened, thanks to your draft. :-) 

I believe that sufficient arguments have been raised against the
progression
of this draft, as it stands, which does not even explicitly states, for
a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely,
only 
errors made by the CA personal or attributed to the CA during the
management
of the certificate, e.g. at the time of registration of the subject,
when
issuing the certificate, when handling revocation requests or when
making
available revocation status information.

Regards,

Denis

> Alice,
> 
> >Lynn observed that the world of financial risk management is moving
past
> >per-transaction model.  The proposed extension offers an aggregate
model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk,
i.e.,
> >aggregated transactions, is the primary worry of the insurance
industry then
> >the aggregate model would be appropriate.
> 
> This sounds pretty dangerous as it gives no value to an RP which may
be just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
> 
> If it is of no value to RPs, the only purpose left for the
warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is
likely
> to be accompanied by a non-machine-interpretable agreement?
> 
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
> 
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
> 
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now
making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
> 
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
> 
> cheers,
> Anders

--Boundary_(ID_5b881ouBlaerftQXl7K/Sg)
Content-type: text/html

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

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>I helped review the first warranty program, for Michael</FONT>
<BR><FONT SIZE=2>Baum's Public Certification Service concept. Whilst I dont </FONT>
<BR><FONT SIZE=2>believe its useful for IETF to focus on</FONT>
<BR><FONT SIZE=2>warranties, I do believe clarifiation of just</FONT>
<BR><FONT SIZE=2>what a CP-based warranty is is useful.</FONT>
</P>

<P><FONT SIZE=2>I dont expect users to ever really understand the</FONT>
<BR><FONT SIZE=2>difference in the legal model between certification, </FONT>
<BR><FONT SIZE=2>representation, warranty, insurance, reliance, etc.</FONT>
</P>

<P><FONT SIZE=2>What they do need to understand however is</FONT>
</P>

<P><FONT SIZE=2>1. The common notion of first-come-first-served </FONT>
<BR><FONT SIZE=2>payout-limits (which means they may get a shock when multiple </FONT>
<BR><FONT SIZE=2>parties all claim for the limited cash)</FONT>
</P>

<P><FONT SIZE=2>2. Warranty execlusions are often structured such that</FONT>
<BR><FONT SIZE=2>few can ever make a valid claim. These warranties</FONT>
<BR><FONT SIZE=2>are just marketing gimics, to puff trustworthiness.</FONT>
<BR><FONT SIZE=2>Valuable warranties are transactional, by banks or</FONT>
<BR><FONT SIZE=2>Japanese trading houses like Mitsui. They really</FONT>
<BR><FONT SIZE=2>dont function as an adjunt to authentication.</FONT>
</P>

<P><FONT SIZE=2>Conclusion: If IETF proceeds, the result should be at most</FONT>
<BR><FONT SIZE=2>an informational RFC.</FONT>
</P>

<P><FONT SIZE=2>N.B.</FONT>
</P>

<P><FONT SIZE=2>My comments - as a practitioner - may sound harsh on public </FONT>
<BR><FONT SIZE=2>CAs. Warranties are appropriate - they just dont have in practice </FONT>
<BR><FONT SIZE=2>the direct&nbsp; benefits that are marketed. The costs of the </FONT>
<BR><FONT SIZE=2>protection plans' insurance is essentially just </FONT>
<BR><FONT SIZE=2>an indirect tax on providing core trustworthiness of</FONT>
<BR><FONT SIZE=2>a TTP-grade CA.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas</FONT>
<BR><FONT SIZE=2>To: [email-masked]</FONT>
<BR><FONT SIZE=2>Cc: Anders Rundgren; [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=2>Sent: 9/2/02 3:50 AM</FONT>
<BR><FONT SIZE=2>Subject: Re: draft-ietf-pkix-warranty-ext-01</FONT>
</P>
<BR>

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

<P><FONT SIZE=2>I concur with many of the arguments raised by Anders. It is very scarce,</FONT>
<BR><FONT SIZE=2>but</FONT>
<BR><FONT SIZE=2>this time it happened, thanks to your draft. :-) </FONT>
</P>

<P><FONT SIZE=2>I believe that sufficient arguments have been raised against the</FONT>
<BR><FONT SIZE=2>progression</FONT>
<BR><FONT SIZE=2>of this draft, as it stands, which does not even explicitly states, for</FONT>
<BR><FONT SIZE=2>a</FONT>
<BR><FONT SIZE=2>naive reader, what the warranty is about.</FONT>
</P>

<P><FONT SIZE=2>The warranty is concerned with the liability of the CA, more precisely,</FONT>
<BR><FONT SIZE=2>only </FONT>
<BR><FONT SIZE=2>errors made by the CA personal or attributed to the CA during the</FONT>
<BR><FONT SIZE=2>management</FONT>
<BR><FONT SIZE=2>of the certificate, e.g. at the time of registration of the subject,</FONT>
<BR><FONT SIZE=2>when</FONT>
<BR><FONT SIZE=2>issuing the certificate, when handling revocation requests or when</FONT>
<BR><FONT SIZE=2>making</FONT>
<BR><FONT SIZE=2>available revocation status information.</FONT>
</P>

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

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

<P><FONT SIZE=2>&gt; Alice,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Lynn observed that the world of financial risk management is moving</FONT>
<BR><FONT SIZE=2>past</FONT>
<BR><FONT SIZE=2>&gt; &gt;per-transaction model.&nbsp; The proposed extension offers an aggregate</FONT>
<BR><FONT SIZE=2>model.</FONT>
<BR><FONT SIZE=2>&gt; &gt;Also Lynn wrote: &quot;and any migration to an offline paradigm with</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; both support for per transaction as well as aggregation risk/limits</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; obsoletes the requirement for the certificate.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt;That's true; that's why the extension is useful.&nbsp; If total risk,</FONT>
<BR><FONT SIZE=2>i.e.,</FONT>
<BR><FONT SIZE=2>&gt; &gt;aggregated transactions, is the primary worry of the insurance</FONT>
<BR><FONT SIZE=2>industry then</FONT>
<BR><FONT SIZE=2>&gt; &gt;the aggregate model would be appropriate.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This sounds pretty dangerous as it gives no value to an RP which may</FONT>
<BR><FONT SIZE=2>be just</FONT>
<BR><FONT SIZE=2>&gt; one of several thousands of RPs which just received a purchase order</FONT>
<BR><FONT SIZE=2>&gt; from a company that is on the edge of filing for bankruptcy.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If it is of no value to RPs, the only purpose left for the</FONT>
<BR><FONT SIZE=2>warranty-extension</FONT>
<BR><FONT SIZE=2>&gt; is for a CA to insert its liability limit in a machine-readable</FONT>
<BR><FONT SIZE=2>&gt; format.&nbsp; Is this really interesting as any liability above zero is</FONT>
<BR><FONT SIZE=2>likely</FONT>
<BR><FONT SIZE=2>&gt; to be accompanied by a non-machine-interpretable agreement?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Is the intent, that the moment a transaction is received that exceeds</FONT>
<BR><FONT SIZE=2>&gt; the liability limit, an alert is to be sent to the legal department?</FONT>
<BR><FONT SIZE=2>&gt; Depending on the liability agreement this may be too late</FONT>
<BR><FONT SIZE=2>&gt; as lower-amount transactions may be equally uncovered.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Actually it would IMO better be a part of the CA-certificate to</FONT>
<BR><FONT SIZE=2>&gt; declare what it stands for in terms of liability.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regarding warranted purchase orders, I have serious problems</FONT>
<BR><FONT SIZE=2>&gt; understanding what a CA-issued warranty could possibly cover except</FONT>
<BR><FONT SIZE=2>&gt; for a liability for having certified the wrong entity which is now</FONT>
<BR><FONT SIZE=2>making</FONT>
<BR><FONT SIZE=2>&gt; fake orders.&nbsp; But IMHO such a warranty is equally applicable to</FONT>
<BR><FONT SIZE=2>&gt; authentications, as incorrect such are even worse as you cannot</FONT>
<BR><FONT SIZE=2>&gt; &quot;rollback&quot; authentication events.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For pure financial transactions, there are already solutions in place</FONT>
<BR><FONT SIZE=2>&gt; since ages ago, like bank-warranties, remburses and pre-paid orders.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; cheers,</FONT>
<BR><FONT SIZE=2>&gt; Anders</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_5b881ouBlaerftQXl7K/Sg)--

Content-return: allowed
Date: Mon, 09 Sep 2002 10:08:57 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Timestamping + Cert revocation + revocation question
To: "'Michael Fritscher '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.

--Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)
Content-type: text/plain

The various signature laws are written with the assumption
that a seperate record management infrastructure keeps the
assurnace of strong authentication uptodate.

Attmepting to remove the obligation to manage records from 
digital signature frameworks, using technical tricks, is 
really going against the legal framework now in place.

I cant the community that got the legal frameworks established 
reformulating their model.

Its much easier (and this is what counts for the American
market) for users to manage a cheap, trusted message store and
storage medium, then solve a global infrastructure and policy 
problem. Auditors require users to maintain records, anyway.

At ValiCert, we never see any real demand for OCSP features
that provided for historical validation, for example. Folks
do integrate the trusted audit log however, signing the
log files of the validation server as evidence of 
proper authentication. Cheap, easy, natural.

BTW, VISA has a patent on some of this area, based on
work we did in root key handling during the SET committe work
in 1995. SET had specific rules on private and public key 
verification periods, and these rules were important
to the proof-of-possesion (card present) service.

-----Original Message-----
From: Michael Fritscher

As I have seen it till now, the only way to be able to verify a
signature is to have some valid (at the time of verification)
certificate for the private key that was used to sign a time-stamp on
another timestamp (or signature combined with a timestamp) valid at
the time of timestamping and so on... This way you get a chain of
trust over time and keep the signatures verifyable.

--Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)
Content-type: text/html

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

<P><FONT SIZE=2>The various signature laws are written with the assumption</FONT>
<BR><FONT SIZE=2>that a seperate record management infrastructure keeps the</FONT>
<BR><FONT SIZE=2>assurnace of strong authentication uptodate.</FONT>
</P>

<P><FONT SIZE=2>Attmepting to remove the obligation to manage records from </FONT>
<BR><FONT SIZE=2>digital signature frameworks, using technical tricks, is </FONT>
<BR><FONT SIZE=2>really going against the legal framework now in place.</FONT>
</P>

<P><FONT SIZE=2>I cant the community that got the legal frameworks established </FONT>
<BR><FONT SIZE=2>reformulating their model.</FONT>
</P>

<P><FONT SIZE=2>Its much easier (and this is what counts for the American</FONT>
<BR><FONT SIZE=2>market) for users to manage a cheap, trusted message store and</FONT>
<BR><FONT SIZE=2>storage medium, then solve a global infrastructure and policy </FONT>
<BR><FONT SIZE=2>problem. Auditors require users to maintain records, anyway.</FONT>
</P>

<P><FONT SIZE=2>At ValiCert, we never see any real demand for OCSP features</FONT>
<BR><FONT SIZE=2>that provided for historical validation, for example. Folks</FONT>
<BR><FONT SIZE=2>do integrate the trusted audit log however, signing the</FONT>
<BR><FONT SIZE=2>log files of the validation server as evidence of </FONT>
<BR><FONT SIZE=2>proper authentication. Cheap, easy, natural.</FONT>
</P>

<P><FONT SIZE=2>BTW, VISA has a patent on some of this area, based on</FONT>
<BR><FONT SIZE=2>work we did in root key handling during the SET committe work</FONT>
<BR><FONT SIZE=2>in 1995. SET had specific rules on private and public key </FONT>
<BR><FONT SIZE=2>verification periods, and these rules were important</FONT>
<BR><FONT SIZE=2>to the proof-of-possesion (card present) service.</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Michael Fritscher</FONT>
</P>

<P><FONT SIZE=2>As I have seen it till now, the only way to be able to verify a</FONT>
<BR><FONT SIZE=2>signature is to have some valid (at the time of verification)</FONT>
<BR><FONT SIZE=2>certificate for the private key that was used to sign a time-stamp on</FONT>
<BR><FONT SIZE=2>another timestamp (or signature combined with a timestamp) valid at</FONT>
<BR><FONT SIZE=2>the time of timestamping and so on... This way you get a chain of</FONT>
<BR><FONT SIZE=2>trust over time and keep the signatures verifyable.</FONT>
<BR><FONT SIZE=2></FONT>&nbsp;
</P>

</BODY>
</HTML>

--Boundary_(ID_sW3MjDDmlKqps04t00xbcQ)--

Date: Mon, 09 Sep 2002 15:59:53 +0200
From: Michael Fritscher <[email-masked]>
To: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

I am working on a thesis on signatures that can be validated over a
long period (similar to the 20 to 30 years mentioned here before).

I now went through the whole thread and got the impression that the
point behind the problems discussed in this thread is that you want to
have different validity periods for the use of the private key and the
use of the public key (correct me if I got that wrong).

IMHO there is no "technical" reason for having different validity
periods. If you can afford to extend the validity period for the
public key (in order to be able to verify a signature/certificate
after the certificate has expired), I see no reason why you could not
extend the validity period of the private key as well.

As I have seen it till now, the only way to be able to verify a
signature is to have some valid (at the time of verification)
certificate for the private key that was used to sign a time-stamp on
another timestamp (or signature combined with a timestamp) valid at
the time of timestamping and so on... This way you get a chain of
trust over time and keep the signatures verifyable.

Michael Fritscher
Any way, at least one valid signature over the rest is necessary.

I am aware of the fact that a chain of trust over time does not
address the problem of handling the verification of signatures whose
private key has been revoked after the signing time.

Date: Mon, 09 Sep 2002 15:42:57 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: David Hopwood <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

David,

> > Marc,
> > > I effectivelly think that for qualified cert and signature with a legal
> > > value, CRL should be maintain during the same period than the validity
> > > period of signatures.
> >
> > This sentence may be quite confusing. CRLs shall be kept by a verifier
> > during the same period than the validity period of the signature. However,
> > the CA is not concerned with any archiving of CRLs during such a time frame.
> >
> > > Thus archiving CRL for 20-30 years it not really enough, we should also
> > > maintain them during this period: we should be able to 'revoke' certs
> > > after expiration.
> >
> > At most, during a reasonable cautionary period, e.g. one month.
> 
> How long revocation needs to be possible for depends on the meaning of the
> certification. For example, in the case of code signing, a certificate carries
> the implication that (someone says that) the principal should be trusted to
> sign only secure code - that is, code that cannot be exploited, as well as not
> being itself malicious. The fact that a principal has been signing flawed code
> (intentionally or not) can discovered at *any* time. The certificate should
> therefore be able to be revoked at *any* point in its lifetime, independent of
> the use of timestamping.

Revocation is independant from timestamping.
 
Any certificate is revokabled at *any* point in its lifetime.

When time-stamping is used, signatures done prior to the revocation time
continue to be valid, if the time-stamp token was applied before the
revocation time.

When time-stamping is *not* used, signatures done prior to the revocation
have to be considered as invalid, unless ther timeliness can be demonstrated 
using other means.

Regards,

Denis

> Some people might argue that the revocation mechanism was never intended
> to be able to handle anything other than the compromise of private keys.
> Regardless, revocation is assumed in many protocols to be a way of
> "taking back" a certification for any reason at all.
> 
> - --
> David Hopwood <[email-masked]>
> 
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private key has been
> seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBPXe5uTkCAxeYt5gVAQEWGgf/VteAjKGLOFc0o9TlR+NGjU7FC6JPuUKs
> Co3lm3OtzsHGdQIdNFtDAGZE0VfmpVvjXgKTxbLoDBYOtn80nMfLR7qnNL6jHRyb
> YiCJYE3sCQViP4K+rgAhDMnwoV1yA7dc7RrkQ8i5shlD5721rWnmL+D80TY/M9X6
> 4dUskeyjWfB+7jv8pqeFGNXJIOSBMvStAESDjm4MgMcwdkvLAUqSdrc0pUXLqe+1
> YfhJHsNlmi/shu0ezLFJ2iHQ5fJ9zUMDgjXcgviqSD5Yej5wJy/6DoX3236iSYfC
> wnvst5rYOJlXo3AludfjuuCIJwungn5U4Q8a5mIB76FqRyNqL6whsw==
> =T2ae
> -----END PGP SIGNATURE-----

Importance: Normal
Sensitivity: 
Subject: Re: Timestamping + Cert revocation + revocation question
To: Denis Pinkas <[email-masked]>
Cc: Marc Jadoul <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Fri, 6 Sep 2002 17:34:13 -0400
Sender: [email-masked]

      Actually, there is no reason to mandate PKU Period in general, just
to recommend it on NR certificates (and probably CA and CRL certificates as
well).  Like Peter, I have never understood why that extension was
deprecated.

            Tom Gindin

Denis Pinkas <[email-masked]>@mail.imc.org on 09/05/2002 09:19:29 AM

Sent by:    [email-masked]

To:    Marc Jadoul <[email-masked]>
cc:    [email-masked]
Subject:    Re: Timestamping + Cert revocation + revocation question

Marc,

(...)

> > > I effectivelly think that for qualified cert and signature with a
legal
> > > value, CRL should be maintain during the same period than the
validity
> > > period of signatures.

> > This sentence may be quite confusing. CRLs shall be kept by a verifier
> > during the same period than the validity period of the signature.
However,
> > the CA is not concerned with any archiving of CRLs during such a time
> frame.

> I am not a legal guy and yes I am probably mixing several issues. But, I
> know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
> information. See point 7.4.11 e) saying that "Recording concerning
qualified
> certificates shall be held for a period of time as appropriate for
providing
> necessary legal evidence in support of electronic signature."

> I thought that this would imply that CRLs need to be archived for a very
> long time.

 ... but they will not be accessible to the public.

(...)

> > In order to solve nicely this issue, there is a need to add extra
> > information "somewhere".

> > 1) One possibilty is to use the private key usage period extension
> >    in a public key certificate.

> > 2) Another possibility would be to use the Archive Cutoff extension
> >    defined in RFC 2560 (OCSP) in section 4.4.4. The only problem
> >    is that we do not have the equivalent for CRLs.

> > Since the later solution would not increase the size of the
certificate,
> > this would have my preference.

> > In RFC 2560, Archive Cutoff is introduced as follows:

> >    An OCSP responder MAY choose to retain revocation information beyond
> >    a certificate's expiration.

> > For CRLs, it would be introduced as follows:

> >    A CRL Issuer MAY choose to retain revocation information beyond
> >    a certificate's expiration.

> I removed the rest of the discussion.

> I agree with you and James Manger that the "private key usage period
> extension" is a response to my concern.

> I agree with Peter Gutmann that I do not understand why it is recommanded
to
> not use it (yet or anymore?) in PKIX.

> I disagree with your second proposition, as I prefer an extension in the
> certificate than in the OCPS response or CRL. If you look at traffic,
OCSP
> and CRLs are downloaded from a few points in the network while
certificate
> eventually follow the signature. CRLs and OCSP traffic can become really
> large if you talk about CAs of more than 10000000 users.

This is not an argument since CRLs or OCSP responses are needed anyway.

> If you take into account the fact that you might need to archive CRLs for
20
> years, you will prefer to have them small, right?

Compared to the size of the CRL, the addition will not be noticeable.

> So this extension could be
> OK for OCSP but please do not add too much to CRLs which might need to be
> reissued every 6 hours and archived for 20 years!
> Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
> again duplication of the info!

> One more argument: the private key usage period extension is really a
> property of the key/certificate, not of the revocation. You want to
> implement in client application the logic for not using the key anymore
> after it expire, you won't use OCSP to check that.
> One last argument: it exist already, we just could make it a PKIX
standard.

The solution would be technically correct, but it would mandate the
presence
of the private key usage period extension.

:-(

Also it would not mimic current situations with credit cards, where a new
credit card is received one month before the expiration of the current one,
but during that month any of them can be used.

There is anyway a solution to this problem which does not require any
extension. Under a given CP, a CA may say that its CRL Issuers continue to
handle revocation one month after the end of the certificate validity
period. This does not scale worldwide, but it works as soon as the CPs to
be
accepted are known by verifiers, which is mostly the case.

An extension in the CRL would make it scalable. Now, if in practice every
CA is fixing the time after which revocation continues to be handled to
6 weeks, is that extension in a CRL really needed ?

Finally, if a CA is only using OCSP responders, the solution already
exists.

Regards,

Denis

> Hope I was readable....
> Best regards,
> Marc

Date: Fri, 06 Sep 2002 16:13:47 -0400
From: Steve Hanna <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: "'Housley, Russ'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: rfc822name Name Constraints question
Sender: [email-masked]

Santosh Chokhani wrote:
> X.509 requires that the name constraints be enforced on hierarchical
> names only. I do not remember the RFC-822 chapter and verse, but I
> thought items to the right of "@" are hierarchical and can be
> enforced. I thought items to the left of "@" is a single address
> string.

That's right. An rfc822Name is an RFC 822 addr-spec. To the
left of "@" is the local-part, which is a string with no
standard structure. To the right of "@" is the domain, which
has a hierarchical structure. These days, the domain is
generally a DNS domain name.

The domain has a hierarchical structure, so it makes sense for
RFC 3280 to allow you to specify only the uppermost portions
of the domain in a name constraint. The local-part has no
standard structure (although local domains could establish
their own structure). So it's good that RFC 3280 (at least, as
I read it) doesn't provide any way to specify a portion
of the local-part in a name constraint.

> In short, RFC 3280 should enforce hierarchical aspects of
> RFC 822 names.

Agreed.

-Steve

From: [email-masked]
To: <[email-masked]>
Cc: "Alice Sturgeon" <[email-masked]>, "Denis Pinkas" <[email-masked]>, "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Fri, 06 Sep 2002 01:57:20 +0000
Sender: [email-masked]

Alice,

Some points/suggestions:

1.)  There is a minor typo on page 5, para 2, line 1.

The �if� in the line (copied below) should probably 
be 'of'.

 "CurrencyAmount is a SEQUENCE if three integers.  
Together the integers..."
 
2.) The draft says:
"The extension definition supports two alternatives: 
aggregated and per-transaction." 

Often, it is desirable to limit both the per transaction 
liability as well as the aggregated liability.  e.g. 
$100.00 max per transaction with a $500.00 max for the 
life of the certificate.  I would recommend that this be 
accommodated.

3.) I recall hearing some noise in the past about a 
Certco patent on issuing ANY kind of warranty where a RP 
uses a certificate to determine the warranty.  ...or 
something along those lines.  Do you know if this ID is 
(or is not) hampered by this patent? 

Others on the list have questioned whether this ID is 
really a necessary thing.  I happen to think that such 
an extension can be put to good use and may facilitate 
automated validation of an electronic transaction in 
some cases.  It certainly does no harm.   That said, 
there will be situations where the requirements are too 
complex to be handled by such an extension to any degree 
of usefulness. (like Identrus - which had a multi-
currency, cross jurisdiction, per transaction setting of 
warranty cost and value based on dynamic lookups of caps 
and collateral, etc) For such complex systems, the best 
place to handle warranty statements is the CP or some 
related document and not a certificate extension.  

Khaja

> 
> Denis and Anders, I appreciate your comments; they are 
helpful in keeping to
> the right path.
> 
> One point that I took issue with was Denis' to the 
effect that the intent of
> the I-D is not clear.  It is in fact stated in the 
first couple of
> paragraphs and I would have thought it quite clear. It 
is to provide a
> degree of confidence to RPs in e-business and 
electronic transactions. PKI
> is seriously not yet understood; there exists some 
mistrust amongst
> potential users about the mechanisms, not necessarily 
the security
> mechanisms per se because these are relatively 
transparent to a user, but
> generally in electronic exchanges involving some value.
> 
> I also have a problem with Anders' statement that you 
cannot "roll-back"
> authentication events.  True technically (actually, 
technically either true
> or false depending on mechanisms); in a legal or 
policy context isn't this
> what non-repudiation prohibits? That is, without non-
repudiation, you can
> "undo" an authentication event (the authentication can 
be repudiated, or
> 'undone').
> 
> I'm looking forward to being able to discuss issues 
about the I-D at the
> Atlanta IETF meeting.  I'm sure others will as well, 
since there have been a
> number of respondents to the I-D posting.  Just FYI, 
my unaudited (but
> trustworthy : - )) count shows 5 supporters, 3 
objectors, 2 abstainers, and
> 2 still considering and undecided.
> 
> 
> Alice
> 
> P.S. Denis, I'm happy to have been the source of 
bringing you and Anders to
> like thinking!
> 
> Alice Sturgeon
> Chair
> Canadian Advisory Committee - Information Technology 
Security
> ISO/IEC JTC1 SC 27
> and
> System Policy Architect
> SPYRUS
> Phone:     613-232-2350
> Cell:         613-291-0331
> 
> 
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: September 2, 2002 6:50 AM
> To: [email-masked]
> Cc: Anders Rundgren; [email-masked]; ietf-
[email-masked]
> Subject: Re: draft-ietf-pkix-warranty-ext-01
> 
> Alice,
> 
> I concur with many of the arguments raised by Anders. 
It is very scarce, but
> this time it happened, thanks to your draft. :-)
> 
> I believe that sufficient arguments have been raised 
against the progression
> of this draft, as it stands, which does not even 
explicitly states, for a
> naive reader, what the warranty is about.
> 
> The warranty is concerned with the liability of the 
CA, more precisely, only
> errors made by the CA personal or attributed to the CA 
during the management
> of the certificate, e.g. at the time of registration 
of the subject, when
> issuing the certificate, when handling revocation 
requests or when making
> available revocation status information.
> 
> Regards,
> 
> Denis
> 
> > Alice,
> >
> > >Lynn observed that the world of financial risk 
management is moving past
> > >per-transaction model.  The proposed extension 
offers an aggregate model.
> > >Also Lynn wrote: "and any migration to an offline 
paradigm with
> > >> both support for per transaction as well as 
aggregation risk/limits
> > >> obsoletes the requirement for the certificate."
> > >That's true; that's why the extension is useful.  
If total risk, i.e.,
> > >aggregated transactions, is the primary worry of 
the insurance industry
> then
> > >the aggregate model would be appropriate.
> >
> > This sounds pretty dangerous as it gives no value to 
an RP which may be
> just
> > one of several thousands of RPs which just received 
a purchase order
> > from a company that is on the edge of filing for 
bankruptcy.
> >
> > If it is of no value to RPs, the only purpose left 
for the
> warranty-extension
> > is for a CA to insert its liability limit in a 
machine-readable
> > format.  Is this really interesting as any liability 
above zero is likely
> > to be accompanied by a non-machine-interpretable 
agreement?
> >
> > Is the intent, that the moment a transaction is 
received that exceeds
> > the liability limit, an alert is to be sent to the 
legal department?
> > Depending on the liability agreement this may be too 
late
> > as lower-amount transactions may be equally 
uncovered.
> >
> > Actually it would IMO better be a part of the CA-
certificate to
> > declare what it stands for in terms of liability.
> >
> > Regarding warranted purchase orders, I have serious 
problems
> > understanding what a CA-issued warranty could 
possibly cover except
> > for a liability for having certified the wrong 
entity which is now making
> > fake orders.  But IMHO such a warranty is equally 
applicable to
> > authentications, as incorrect such are even worse as 
you cannot
> > "rollback" authentication events.
> >
> > For pure financial transactions, there are already 
solutions in place
> > since ages ago, like bank-warranties, remburses and 
pre-paid orders.
> > cheers,
> > Anders

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Thu, 5 Sep 2002 17:12:38 -0400
Importance: Normal
Sender: [email-masked]

Denis and Anders, I appreciate your comments; they are helpful in keeping to
the right path.

One point that I took issue with was Denis' to the effect that the intent of
the I-D is not clear.  It is in fact stated in the first couple of
paragraphs and I would have thought it quite clear. It is to provide a
degree of confidence to RPs in e-business and electronic transactions. PKI
is seriously not yet understood; there exists some mistrust amongst
potential users about the mechanisms, not necessarily the security
mechanisms per se because these are relatively transparent to a user, but
generally in electronic exchanges involving some value.

I also have a problem with Anders' statement that you cannot "roll-back"
authentication events.  True technically (actually, technically either true
or false depending on mechanisms); in a legal or policy context isn't this
what non-repudiation prohibits? That is, without non-repudiation, you can
"undo" an authentication event (the authentication can be repudiated, or
'undone').

I'm looking forward to being able to discuss issues about the I-D at the
Atlanta IETF meeting.  I'm sure others will as well, since there have been a
number of respondents to the I-D posting.  Just FYI, my unaudited (but
trustworthy : - )) count shows 5 supporters, 3 objectors, 2 abstainers, and
2 still considering and undecided.

Alice

P.S. Denis, I'm happy to have been the source of bringing you and Anders to
like thinking!

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

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: September 2, 2002 6:50 AM
To: [email-masked]
Cc: Anders Rundgren; [email-masked]; [email-masked]
Subject: Re: draft-ietf-pkix-warranty-ext-01

Alice,

I concur with many of the arguments raised by Anders. It is very scarce, but
this time it happened, thanks to your draft. :-)

I believe that sufficient arguments have been raised against the progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely, only
errors made by the CA personal or attributed to the CA during the management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.

Regards,

Denis

> Alice,
>
> >Lynn observed that the world of financial risk management is moving past
> >per-transaction model.  The proposed extension offers an aggregate model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk, i.e.,
> >aggregated transactions, is the primary worry of the insurance industry
then
> >the aggregate model would be appropriate.
>
> This sounds pretty dangerous as it gives no value to an RP which may be
just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
>
> If it is of no value to RPs, the only purpose left for the
warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is likely
> to be accompanied by a non-machine-interpretable agreement?
>
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
>
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
>
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
>
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
>
> cheers,
> Anders

Date: Thu, 05 Sep 2002 20:09:19 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

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

Denis Pinkas wrote:
> Marc,
> > I effectivelly think that for qualified cert and signature with a legal
> > value, CRL should be maintain during the same period than the validity
> > period of signatures.
> 
> This sentence may be quite confusing. CRLs shall be kept by a verifier
> during the same period than the validity period of the signature. However,
> the CA is not concerned with any archiving of CRLs during such a time frame.
> 
> > Thus archiving CRL for 20-30 years it not really enough, we should also
> > maintain them during this period: we should be able to 'revoke' certs
> > after expiration.
> 
> At most, during a reasonable cautionary period, e.g. one month.

How long revocation needs to be possible for depends on the meaning of the
certification. For example, in the case of code signing, a certificate carries
the implication that (someone says that) the principal should be trusted to
sign only secure code - that is, code that cannot be exploited, as well as not
being itself malicious. The fact that a principal has been signing flawed code
(intentionally or not) can discovered at *any* time. The certificate should
therefore be able to be revoked at *any* point in its lifetime, independent of
the use of timestamping.

Some people might argue that the revocation mechanism was never intended
to be able to handle anything other than the compromise of private keys.
Regardless, revocation is assumed in many protocols to be a way of
"taking back" a certification for any reason at all.

- -- 
David Hopwood <[email-masked]>

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

Date: Thu, 05 Sep 2002 17:42:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Marc Jadoul <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

Marc,

> Hello Denis,
> 
> I do not know if the problem of the credit card is the same as the one of
> legally valid signature and qualified certificates I was tinking about.
> 
> (...)
> 
> >  ... but they (archived CRLs)  will not be accessible to the public.
 
> We are still talking about TByte of CRL's data to archive and Gbit/s of
> bandwidth for relying party to download the last CRL. In fact, do you intent
> to add the extension as a CRL entry extension or a global CRL extension? 

A global CRL extension. Look at the definition archive cutoff in RFC 2560.

> For me the private key validity period depend of the lenght of the private 
> key of the user and thus is probably a CRL entry extension. That mean that 
> you might have an CRL entry which is 50% bigger. Instead of having 1TB you 
> would need 1.5TB of storage and same caculation can be done for needed 
> bandwidth.

We are not talking of a private key validity period, and we are not
discussing key length strengths for a period of one month.
 
> (...)
> 
> > This is not an argument since CRLs or OCSP responses are needed anyway.
> 
> See above. I would like to minimize the bandwidth/storage needed for a CA,
> thus price/certificate.
> 
> (...)
> 
> > Compared to the size of the CRL, the addition will not be noticeable.
> 
> See above: depend if you talk about a CRL Entry Extension or a CRL
> Extension.
> 
> (...)
> 
> > Also it would not mimic current situations with credit cards, where a new
> > credit card is received one month before the expiration of the current
> > one, but during that month any of them can be used.
> 
> I do not completly understand this. Couldn't you have the new private key
> valid 1 month before the old private key expire?

Yes, but during this period the signer could use any of them.

> Obviously, you are talking of maintaining the CRL for 1 additional month
> after expiration of a private key himself usable for (5 years + 1 month)
> (credit card model) 

Yes.

> while I think in term of qualified certificates with a
> private key usable during (5 years + 1 month) and maintaining revocation
> info for 20 years for instance.

Revocation information needs to be captured close to the time the signature
is issued to make sure that the signature is valid. The intent is NOT to ask
the CRL issuer to keep that information for 20 years.
 
> > There is anyway a solution to this problem which does not require any
> > extension. Under a given CP, a CA may say that its CRL Issuers continue to
> > handle revocation one month after the end of the certificate validity
> > period. This does not scale worldwide, but it works as soon as the CPs to
> > be accepted are known by verifiers, which is mostly the case.
> >
> > An extension in the CRL would make it scalable. Now, if in practice every
> > CA is fixing the time after which revocation continues to be handled to
> > 6 weeks, is that extension in a CRL really needed ?
> >
> > Finally, if a CA is only using OCSP responders, the solution already
> > exists.
> 
> May be like nice technical solutions too much.

Let us wait for the opinion of others.

Regards,

Denis
 
> Kind regards,
> Marc

From: "Marc Jadoul" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Thu, 5 Sep 2002 17:09:47 +0200
Sender: [email-masked]

Hello Denis,

I do not know if the problem of the credit card is the same as the one of
legally valid signature and qualified certificates I was tinking about.

(...)

>  ... but they (archived CRLs)  will not be accessible to the public.

We are still talking about TByte of CRL's data to archive and Gbit/s of
bandwidth for relying party to download the last CRL. In fact, do you intent
to add the extension as a CRL entry extension or a global CRL extension? For
me the private key validity period depend of the lenght of the private key
of the user and thus is probably a CRL entry extension. That mean that you
might have an CRL entry which is 50% bigger. Instead of having 1TB you would
need 1.5TB of storage and same caculation can be done for needed bandwidth.

(...)

> This is not an argument since CRLs or OCSP responses are needed anyway.

See above. I would like to minimize the bandwidth/storage needed for a CA,
thus price/certificate.

(...)

> Compared to the size of the CRL, the addition will not be noticeable.

See above: depend if you talk about a CRL Entry Extension or a CRL
Extension.

(...)

> Also it would not mimic current situations with credit cards, where a new
> credit card is received one month before the expiration of the current
one,
> but during that month any of them can be used.

I do not completly understand this. Couldn't you have the new private key
valid 1 month before the old private key expire?
Obviously, you are talking of maintaining the CRL for 1 additional month
after expiration of a private key himself usable for (5 years + 1 month)
(credit card model) while I think in term of qualified certificates with a
private key usable during (5 years + 1 month) and maintaining revocation
info for 20 years for instance.

> There is anyway a solution to this problem which does not require any
> extension. Under a given CP, a CA may say that its CRL Issuers continue to
> handle revocation one month after the end of the certificate validity
> period. This does not scale worldwide, but it works as soon as the CPs to
be
> accepted are known by verifiers, which is mostly the case.
>
> An extension in the CRL would make it scalable. Now, if in practice every
> CA is fixing the time after which revocation continues to be handled to
> 6 weeks, is that extension in a CRL really needed ?
>
> Finally, if a CA is only using OCSP responders, the solution already
exists.

May be like nice technical solutions too much.

Kind regards,

Marc

Date: Thu, 05 Sep 2002 15:19:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Marc Jadoul <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

Marc,

(...)

> > > I effectivelly think that for qualified cert and signature with a legal
> > > value, CRL should be maintain during the same period than the validity
> > > period of signatures.

> > This sentence may be quite confusing. CRLs shall be kept by a verifier
> > during the same period than the validity period of the signature. However,
> > the CA is not concerned with any archiving of CRLs during such a time
> frame.
 
> I am not a legal guy and yes I am probably mixing several issues. But, I
> know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
> information. See point 7.4.11 e) saying that "Recording concerning qualified
> certificates shall be held for a period of time as appropriate for providing
> necessary legal evidence in support of electronic signature."

> I thought that this would imply that CRLs need to be archived for a very
> long time.

 ... but they will not be accessible to the public.

(...) 

> > In order to solve nicely this issue, there is a need to add extra
> > information "somewhere".

> > 1) One possibilty is to use the private key usage period extension
> >    in a public key certificate.

> > 2) Another possibility would be to use the Archive Cutoff extension
> >    defined in RFC 2560 (OCSP) in section 4.4.4. The only problem 
> >    is that we do not have the equivalent for CRLs.

> > Since the later solution would not increase the size of the certificate,
> > this would have my preference.

> > In RFC 2560, Archive Cutoff is introduced as follows:

> >    An OCSP responder MAY choose to retain revocation information beyond
> >    a certificate's expiration.

> > For CRLs, it would be introduced as follows:

> >    A CRL Issuer MAY choose to retain revocation information beyond
> >    a certificate's expiration.
 
> I removed the rest of the discussion.

> I agree with you and James Manger that the "private key usage period
> extension" is a response to my concern.

> I agree with Peter Gutmann that I do not understand why it is recommanded to
> not use it (yet or anymore?) in PKIX.

> I disagree with your second proposition, as I prefer an extension in the
> certificate than in the OCPS response or CRL. If you look at traffic, OCSP
> and CRLs are downloaded from a few points in the network while certificate
> eventually follow the signature. CRLs and OCSP traffic can become really
> large if you talk about CAs of more than 10000000 users.

This is not an argument since CRLs or OCSP responses are needed anyway. 

> If you take into account the fact that you might need to archive CRLs for 20
> years, you will prefer to have them small, right? 

Compared to the size of the CRL, the addition will not be noticeable.

> So this extension could be
> OK for OCSP but please do not add too much to CRLs which might need to be
> reissued every 6 hours and archived for 20 years!
> Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
> again duplication of the info!

> One more argument: the private key usage period extension is really a
> property of the key/certificate, not of the revocation. You want to
> implement in client application the logic for not using the key anymore
> after it expire, you won't use OCSP to check that.
> One last argument: it exist already, we just could make it a PKIX standard.

The solution would be technically correct, but it would mandate the presence
of the private key usage period extension. 

:-(

Also it would not mimic current situations with credit cards, where a new
credit card is received one month before the expiration of the current one,
but during that month any of them can be used.

There is anyway a solution to this problem which does not require any
extension. Under a given CP, a CA may say that its CRL Issuers continue to
handle revocation one month after the end of the certificate validity
period. This does not scale worldwide, but it works as soon as the CPs to be
accepted are known by verifiers, which is mostly the case.

An extension in the CRL would make it scalable. Now, if in practice every 
CA is fixing the time after which revocation continues to be handled to 
6 weeks, is that extension in a CRL really needed ? 

Finally, if a CA is only using OCSP responders, the solution already exists.

Regards,

Denis
 
> Hope I was readable....
> Best regards,
> Marc

From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "pkix" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
Date: Thu, 5 Sep 2002 14:45:16 +0200
Importance: Normal
Sender: [email-masked]

Denis,

Sorry for the date mix-up. It's my fault.
The Majority of the draft was written during the Yokohama meeting but
vacations took it longer to get it out of our computers.

Regarding the community logotype I slightly disagree with your text
proposal.
This is a technical standard and this is not the place to dictate what it
takes to have the right to use a certain logotype,
which is a separate and complicated legal issue solved on a business basis.

The only thing we can say for sure is that the presence of a community
logotype is a statement by the issuer that it claims to have the right to
use this logotype according to whatever rules the owner of the logotype has
set up for its legitimate use.

I'm not sure that it's always right to say that the issuer needs to be a
"member" of that community. The thing that matters is that the issuer has
obtained the right for the particular certificate in question. But that
depends on what meaning you attach to "member" and I'm not sure if that word
has a defined legal meaning that limits the scope beyond what we want to
dictate.

/Stefan

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, September 05, 2002 12:23 PM
> To: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
>
>
>
> > A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> > This draft is a work item of the Public-Key Infrastructure
> (X.509) Working Group of the IETF.
> >
> >         Title           : Internet X.509 Public Key
> Infrastructure Logotypes in
> >                           X.509 certificates
> >         Author(s)       : S. Santesson, R. Housley, T. Freeman
> >         Filename        : draft-ietf-pkix-logotypes-04.txt
> >         Pages           : 19
> >         Date            : 2002-9-3
>
> On the top page the document is marked: June 2002.
> On the next pages it is marked: July 2002.
> The document has been issued in September 2002.
>
> :-(
>
> The current definition of a community logotype is as follows:
>
>    The community logotype - is the general mark for a community. It
>    identifies a service concept for entity identification and
>    certificate issuance. Many issuers may use a community logotype to
>    co-brand with a global community in order to gain global recognition
>    of its local service provision. This type of community branding is
>    very common in the credit card business where local independent card
>    issuers include a globally recognized brand (such as VISA and
>    MasterCard).
>
> I would propose to rephrase it the following way, so that it is more
> apparent that the community logotype relates to the issuer.
>
>    The community logotype - is a logotype representing the
>    community or communities to which the certificate issuer belongs to.
>    This general mark for a community may only be used when the issuer
>    has satisfied all the conditions required by that community. These
>    conditions generally include rules for entity identification and
>    revocation requests as well as technical standards to be supported
>    for certificate issuance and certificate revocation status
> availability.
>    Many issuers may use a community logotype to co-brand with a global
>    community in order to gain global recognition of its local service
>    provision. This type of community branding is very common in the
>    credit card business where local independent card issuers include
>    a globally recognized brand (such as VISA and MasterCard).
>
>
> Denis
>

Date: Thu, 05 Sep 2002 12:22:33 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
Sender: [email-masked]

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
>         Title           : Internet X.509 Public Key Infrastructure Logotypes in
>                           X.509 certificates
>         Author(s)       : S. Santesson, R. Housley, T. Freeman
>         Filename        : draft-ietf-pkix-logotypes-04.txt
>         Pages           : 19
>         Date            : 2002-9-3

On the top page the document is marked: June 2002.
On the next pages it is marked: July 2002.
The document has been issued in September 2002.

:-(

The current definition of a community logotype is as follows:

   The community logotype - is the general mark for a community. It
   identifies a service concept for entity identification and
   certificate issuance. Many issuers may use a community logotype to
   co-brand with a global community in order to gain global recognition
   of its local service provision. This type of community branding is
   very common in the credit card business where local independent card
   issuers include a globally recognized brand (such as VISA and
   MasterCard).

I would propose to rephrase it the following way, so that it is more
apparent that the community logotype relates to the issuer. 

   The community logotype - is a logotype representing the
   community or communities to which the certificate issuer belongs to.
   This general mark for a community may only be used when the issuer 
   has satisfied all the conditions required by that community. These 
   conditions generally include rules for entity identification and 
   revocation requests as well as technical standards to be supported 
   for certificate issuance and certificate revocation status availability. 
   Many issuers may use a community logotype to co-brand with a global 
   community in order to gain global recognition of its local service 
   provision. This type of community branding is very common in the 
   credit card business where local independent card issuers include 
   a globally recognized brand (such as VISA and MasterCard).

Denis

From: "Marc Jadoul" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Thu, 5 Sep 2002 11:48:53 +0200
Sender: [email-masked]

Thanks to you all for your responses.
I put all my comment in this email instead of responding to Peter Gutmann,
James Manger and you in 3 emails.

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 05, 2002 9:31 AM
Subject: Re: Timestamping + Cert revocation + revocation question

> Marc,
>
> > Thanks Denis.
>
> > It is interresting.
>
> > I effectivelly think that for qualified cert and signature with a legal
> > value, CRL should be maintain during the same period than the validity
> > period of signatures.
>
> This sentence may be quite confusing. CRLs shall be kept by a verifier
> during the same period than the validity period of the signature. However,
> the CA is not concerned with any archiving of CRLs during such a time
frame.

I am not a legal guy and yes I am probably mixing several issues. But, I
know that ETSI TS 101 456 v1.2.1 require the CA to archive a lot of
information. See point 7.4.11 e) saying that "Recording concerning qualified
certificates shall be held for a period of time as appropriate for providing
necessary legal evidence in support of electronic signature."
I thought that this would imply that CRLs need to be archived for a very
long time.

> > Thus archiving CRL for 20-30 years it not really enought, we should also
> > maintain them during this period: we should be able to 'revoke' certs
> > after expiration.
>
> At most, during a reasonable cautionary period, e.g. one month.

Humm...

> > By adding Timestamping to PKI that was originaly foreseen for realtime
> > authentication, we add additional complexity and the original PKI design
> > show their limits. The Validity Period in a certificate means originally
> > that the certificate could be accepted in realtime during this Validity
> > Period. Thus it was logical to maintain CRLs only during this period.
But
> > know that a certificate could be accepted long after his expiration,
> > revocation information should be maintain during the whole life of the
> > certificate.

... cut ...

> We have this in X.509, but not in RFC 3280. This is the private key usage
> period extension.
>
> Using it, would mean that the period of use of the private key would be,
let
> us say, one month shorter than the period of use of the public key. So the
> digital signature would then need to be time-stamped before the end of the
> private key period. In this way revocation will still be handled one month
> after.
>
> Whatever way we are looking to this problem, revocation needs to be
handled
> a few weeks after the use of the private key. Since it is impossible to
know
> exactly when the private key has been used, an upper limit is used instead
> by using the date included in a time-stamp token over the digital
signature.
>
> > Revocation Info should be maintain during the 2nd Validity Period and
not the first as today.
>
> This is one possibility, as explained in details above.
>
> In order to solve nicely this issue, there is a need to add extra
> information "somewhere".
>
> 1) One possibilty is to use the private key usage period extension
>    in a public key certificate.
>
> 2) Another possibility would be to use the Archive Cutoff extension
defined
>    in RFC 2560 (OCSP) in section 4.4.4. The only problem is that we do not
>    have the equivalent for CRLs.
>
> Since the later solution would not increase the size of the certificate,
> this would have my preference.
>
> In RFC 2560, Archive Cutoff is introduced as follows:
>
>    An OCSP responder MAY choose to retain revocation information beyond
>    a certificate's expiration.
>
> For CRLs, it would be introduced as follows:
>
>    A CRL Issuer MAY choose to retain revocation information beyond
>    a certificate's expiration.

I removed the rest of the discussion.
I agree with you and James Manger that the "private key usage period
extension" is a response to my concern.
I agree with Peter Gutmann that I do not understand why it is recommanded to
not use it (yet or anymore?) in PKIX.
I disagree with your second proposition, as I prefer an extension in the
certificate than in the OCPS response or CRL. If you look at traffic, OCSP
and CRLs are downloaded from a few points in the network while certificate
eventually follow the signature. CRLs and OCSP traffic can become really
large if you talk about CAs of more than 10000000 users.
If you take into account the fact that you might need to archive CRLs for 20
years, you will prefer to have them small, right? So this extension could be
OK for OCSP but please do not add too much to CRLs which might need to be
reissued every 6 hours and archived for 20 years!
Additionnally, as a CA we would propose OCSP but still issue CRLs. Thus
again duplication of the info!
One more argument: the private key usage period extension is really a
property of the key/certificate, not of the revocation. You want to
implement in client application the logic for not using the key anymore
after it expire, you won't use OCSP to check that.
One last argument: it exist already, we just could make it a PKIX standard.

Hope I was readable....

Best regards,

Marc

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: Logos: 04: ~editorial comments
Date: Thu, 5 Sep 2002 19:27:18 +1000 
Sender: [email-masked]

1.
The URI fields (imageURI, audioURI and refStructURI) are all a SEQUENCE OF
IA5String.  There is no mention about why multiple URIs can be included or
how they should be handled.  I am guessing that they are supposed to be
alternative URIs for exactly the same item.  Consequently, a client can use
any URI from the sequence.  If a URI fails, the client should try another.
If so, a sentence to that affect would help.

2.
Renaming the imageFormat and audioFormat fields to imageSubtype and
audioSubtype should make it clearer (in code, not just an ASN.1 comment)
that the fields hold MIME subtypes.

3.
Community, issuer, subject & loyalty types tell you what a logo is related
to.  Whether a logo can be used as a background image is a different style
of information.  Instead of defining id-logo-background, how about including
a flag in LogotypeImageInfo.
	LogotypeImageInfo ::= SEQUENCE {
		...
		background	BOOLEAN DEFAULT FALSE }

	If background is true it indicates that the image is appropriate
	for use as a background image for other certificate details, in
which case
	it MUST allow black text placed over the image to be clearly
readable.

4.
That logos can - to some degree - circumvent name constraints is understood
and explained in the Security considerations section.  A client can take
steps to minimise this risk by, for instance, consistently displaying logos
in a separate, clearly delineated, section of the screen -- so at least a
careful user would not be fooled.  Using a logo as a background image seems
to make this much harder -- now the client would need to, say, make the logo
wobble for a careful user to be able to distinguish what come from the logo
and what is generated by the (trusted) client.  Perhaps background images
should not be supported.

> ----------
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, 4 September 2002 9:57 pm
> 
> 	Title		: Internet X.509 Public Key Infrastructure Logotypes
> in X.509 certificates
> 	Author(s)	: S. Santesson, R. Housley, T. Freeman
> 	Filename	: draft-ietf-pkix-logotypes-04.txt
> 	Pages		: 19
> 	Date		: 2002-9-3
> 	
> This document specifies a certificate extension for including logotypes in
> public key certificates and attribute certificates.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-logotypes-04.txt
> 

Date: Thu, 05 Sep 2002 09:31:06 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Marc Jadoul <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

Marc,

> Thanks Denis.

> It is interresting.

> I effectivelly think that for qualified cert and signature with a legal
> value, CRL should be maintain during the same period than the validity
> period of signatures. 

This sentence may be quite confusing. CRLs shall be kept by a verifier
during the same period than the validity period of the signature. However,
the CA is not concerned with any archiving of CRLs during such a time frame.

> Thus archiving CRL for 20-30 years it not really enought, we should also 
> maintain them during this period: we should be able to 'revoke' certs 
> after expiration.

At most, during a reasonable cautionary period, e.g. one month.

> By adding Timestamping to PKI that was originaly foreseen for realtime
> authentication, we add additional complexity and the original PKI design
> show their limits. The Validity Period in a certificate means originally
> that the certificate could be accepted in realtime during this Validity
> Period. Thus it was logical to maintain CRLs only during this period. But
> know that a certificate could be accepted long after his expiration,
> revocation information should be maintain during the whole life of the
> certificate. 

No. See above.

> And the Validity Period of the certificate only concern the
> time where the action is done, not anymore the time where the action is
> verified.

No.

> May be we should have 2 Validity Period in the certificate: one for when the
> cert can be used to sign and the other when the cert can be used for
> verifying. 

We have this in X.509, but not in RFC 3280. This is the private key usage
period extension.

Using it, would mean that the period of use of the private key would be, let
us say, one month shorter than the period of use of the public key. So the
digital signature would then need to be time-stamped before the end of the
private key period. In this way revocation will still be handled one month
after.

Whatever way we are looking to this problem, revocation needs to be handled
a few weeks after the use of the private key. Since it is impossible to know
exactly when the private key has been used, an upper limit is used instead
by using the date included in a time-stamp token over the digital signature.

> Revocation Info should be maintain during the 2nd Validity Period and not the first as today.

This is one possibility, as explained in details above.

In order to solve nicely this issue, there is a need to add extra
information "somewhere".

1) One possibilty is to use the private key usage period extension 
   in a public key certificate.

2) Another possibility would be to use the Archive Cutoff extension defined 
   in RFC 2560 (OCSP) in section 4.4.4. The only problem is that we do not 
   have the equivalent for CRLs.

Since the later solution would not increase the size of the certificate, 
this would have my preference.

In RFC 2560, Archive Cutoff is introduced as follows:
 
   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. 

For CRLs, it would be introduced as follows:

   A CRL Issuer MAY choose to retain revocation information beyond
   a certificate's expiration. 

Regards,

Denis

> Best Regards,
> Marc
> 
> ----- Original Message -----
> From: "Denis Pinkas" <[email-masked]>
> To: "Marc Jadoul" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 04, 2002 2:46 PM
> Subject: Re: Timestamping + Cert revocation + revocation question
> 
> >
> > Marc,
> >
> > [Next time, please use text editing, instead of HTML editing]
> >
> > > Hi, I probably misunderstood something and I have a small question about
> > > how to 'invalidate' a certificate that has already expired.
> >
> > Quite a strange formulation.
> >
> > > Here is a simple scenario:
> >
> > > User A get controle on a certificate certifying User B. It
> > > create a signature in the name of user B. It then timestamp this
> > > signature.Now User B do not know this. The certificate expire and it is
> > > not possible to revoke it anymore (right?).
> >
> > RFC 3280 states:
> >
> >    An entry MUST NOT be removed from the CRL until it appears on one
> >    regularly scheduled CRL issued beyond the revoked certificate's
> >    validity period.
> >
> > This is a minimum condition.
> >
> > RFC 3125 states:
> >
> > B.8.3  Timing Constraints - Caution Period
> >
> >    Before an electronic signature may really be valid, the verifier has
> >    to be sure that the holder of the private key was really the only one
> >    in possession of key at the time of signing.  However, there is an
> >    inevitable delay between a compromise or loss of key being noted, and
> >    a report of revocation being distributed.  To allow greater
> >    confidence in the validity of a signature, a "cautionary period" may
> >    be identified before a signature may be said to be valid with high
> >    confidence.  A verifier may revalidate a signature after this
> >    cautionary signature, or wait for this period before validating a
> >    signature. The validation policy may specify such a cautionary period.
> >
> > This would mean that the CA should continue, at least, to make available
> > the revocation status information until the end of the cautionnary period.
> > However, there are two problems:
> >
> >   1) the CA is ignorant about the duration of the various cautionary
> >      periods from the various signature/validation policies.
> >
> >   2) unless using the CPS, the CA has no way to indicate how long after
> >      the end of the certificate validity period, it will maintain the
> >      revocation status information ... and the CPS is not directly machine
> >      processable.
> >
> > > The time-stamped signature is
> > > thus valid and I do not know any mean to communicate that the
> certificate
> > > was wrong from the begining. Any relying party will continue to accept
> the
> > > time-stamped signature, even if User B and the CA now know the there was
> a
> > > problem with the certificate at the time of the signature.
> >
> > Whether or not the certificate has expired, a user who does not know that
> > his private key has been compromised may be issuing "valid" signatures
> > without knowing it.
> >
> > In a CRL, it is possible to include an invalidity date that provides the
> > date on which it is known or suspected that the private key was
> compromised.
> > This date may be earlier than the revocation date in the CRL entry.
> >
> > However, any CRL fetched soon after the cautionary period is sufficient to
> > prove that the signature was valid. So a fresher CRL would not
> > help to declare the signature invalid if it is issued after the end of the
> > cautionary period. The only advantage would be that the CA would have an
> > information about a user declaration of an invalidity date, maybe sooner
> > than the time included in the time-stamp token.
> >
> > > Does it exist
> > > some way to communicate that a certificate was invalid from a specific
> > > date, even if it is known only after expiration of the certificate? How
> to
> > > invalidate a timestamped signature?
> >
> > You seem to be looking for a user declaration of an invalidity date and
> > since the CA will not care about an expired certificate, you wonder where
> > and how this declaration could be done.
> >
> > There are two possible answers to your question:
> >
> > 1) Extend the time period during which the revocation information is
> >    both handled and maintained and indicate the end of that period using
> >    a new (non-critical) CRL extension. That time should be superior to the
> >    cautionary period from the signature policy or the validation policy.
> >    This would cover the cautionary period.
> >
> > 2) Beyond the end of the cautionary period, since anyway this declaration
> >    will not be "visible" in the CRL used to validate the signature
> >    (and picked during the cautionary period), it does not matter where
> that
> >    declaration will be made. Today someone having his car robbed will make
> >    a declaration of robbery to the police. The same happens with door
> keys.
> >    Maybe, in the future, some people will make a declaration of loss for
> >    a private key to the police.
> >
> > Regards,
> >
> > Denis
> >
> > > In the real world you would destroy it but here, it can perfectly be
> duplicated.
> >
> > > Marc Jadoul
> >

Date: Thu, 5 Sep 2002 15:05:26 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

"Manger, James H" <[email-masked]> writes:

>This is already supported -- see X.509 (2000) section 8.2.2.5 Private key
>usage period extension (or section 4.2.1.4 of RFC 3280].

Isn't that deprecated though (or at least it was in 2459)?  I've never
understood why, it seemed like a marvellously useful extension to me.

Peter.

From: "Santosh Chokhani" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, "'Housley, Russ'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: rfc822name Name Constraints question
Date: Wed, 4 Sep 2002 21:53:07 -0400
Importance: Normal
Sender: [email-masked]

Steve and Russ:

X.509 requires that the name constraints be enforced on hierarchical
names only. I do not remember the RFC-822 chapter and verse, but I
thought items to the right of "@" are hierarchical and can be enforced.
I thought items to the left of "@" is a single address string.

In short, RFC 3280 should enforce hierarchical aspects of RFC 822 names.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Steve Hanna
Sent: Wednesday, September 04, 2002 3:40 PM
To: Housley, Russ
Cc: [email-masked]; [email-masked]
Subject: Re: rfc822name Name Constraints question

"Housley, Russ" wrote:
> The email address name constraint contains the right-hand part. So, 
> any email address that exactly matches the right-hand part in the name

> constraint is valid.
> 
> >RFC3280 describes how name constraints for "Internet mail addresses" 
> >may be specified, but is unclear on a few points:
> >
> >1. If the NameConstraint is "[email-masked]", does that include
> >    "[email-masked]"?
> 
> Yes.  The email address "[email-masked]" does satisfy the 
> "[email-masked]" constraint.

I was surprised to see this answer. Here's the relevant text from RFC
3280 (section 4.2.1.11):

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example, "[email-masked]"
   indicates the root mailbox on the host "xyz.com".  To indicate all
   Internet mail addresses on a particular host, the constraint is
   specified as the host name.  For example, the constraint "xyz.com" is
   satisfied by any mail address at the host "xyz.com".  To specify any
   address within a domain, the constraint is specified with a leading
   period (as with URIs).  For example, ".xyz.com" indicates all the
   Internet mail addresses in the domain "xyz.com", but not Internet
   mail addresses on the host "xyz.com".

I see no indication here that a constraint of "[email-masked]" would be
satisfied by the address "[email-masked]". It seems that the RFC
describes three cases:

1) If the constraint is a complete mail address, then it is
   only satisfied by that mail address.

2) If the constraint is a host name, then it is satisfied by any
   mail address at that host.

3) If the constraint is a host name with a leading period, it is
   satisfied by any address within that domain.

If my analysis is correct, a constraint of "[email-masked]" is only
satisfied by "[email-masked]" (or anything that matches using
case-insensitive matching, since email addresses are case-insensitive).
There's no way to specify a constraint that would match exactly the set
of all email addresses that end in "[email-masked]".

The text of the RFC doesn't seem to support your assertion: "The email
address name constraint contains the right-hand part. So, any email
address that exactly matches the right-hand part in the name constraint
is valid."

> >2. Can "@xyz.com" be used to match all mail addresses at
> >    "xyz.com" but not addresses at "abc.xyz.com?
> 
> Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes 
> (or .forward entries) on the host xyz.com.

Looking at the RFC, the interpretation of the mail address constraint
"@xyz.com" is not defined. It is neither a complete mail address, a host
name, nor a host name with a leading period. However, the constraint
"xyz.com" would accomplish Anne's goal here (matching all mail addresses
at the xyz.com but not addresses at abc.xyz.com).

> >3. The paragraph says the constraint "xyz.com" is satisfied by
> >    "any mail address at the host "xyz.com", and ".xyz.com" is
> >    satisfied by an address within the domain xyz.com, but not
> >    xyz.com itself.  How then do I specify all addresses in the
> >    domain xyz.com AND xyz.com itself?
> 
> The constraint "xyz.com" permits "[email-masked]" and "[email-masked]"

Not according to the RFC as I read it. The constraint "xyz.com" only
permits "[email-masked]" and "[email-masked]", not "[email-masked]". If
you want to specify a constraint that matches all of and only all of the
mail addresses on host xyz.com and all of the mail addresses in the
domain xyz.com, then you'd need to specify two constraint, one being
"xyz.com" and the other being ".xyz.com".

Please explain to me how your interpretation of the RFC is supported by
the text. I don't want to make a federal case out of this, but I also
don't want people to be confused by an erroneous interpretation of the
RFC. And if I'm wrong (or the RFC is wrong), I'd like to know about it.

Thanks,

Steve Hanna

P.S. Anne did not ask me about her question before sending it, in case
you were wondering. I was on vacation last week.

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: Timestamping + Cert revocation + revocation question
Date: Thu, 5 Sep 2002 10:03:47 +1000 
Sender: [email-masked]

	> May be we should have 2 Validity Period in the certificate: one
for when the
	cert can be used to sign and the other when the cert can be used for
	verifying. Revocation Info should be maintain during the 2nd
Validity Period
	and not the first as today.

This is already supported -- see X.509 (2000) section 8.2.2.5 Private key
usage period extension (or section 4.2.1.4 of RFC 3280].

The private key usage period extension (privateKeyUsagePeriod) indicates the
period of valid use of the private key.

The validity field "is the time interval during which the CA warrants that
it will maintain information about the status of the certificate" [X.509,
section 7].

Revocation info is maintained today for what you call the "2nd Validity
Period", it is just that the first is rarely specified.

Date: Wed, 04 Sep 2002 17:28:59 -0400
From: Steve Hanna <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Standard for Name Constraints for X500Names
Sender: [email-masked]

Anne Anderson wrote:
> In RFC3280, I do not find an algorithm or reference for how
> X500Name NameConstraints are compared.  I know that the empty
> string is the root of the X500 name space, but..
> 
> If A is constrained by B,
> - must A include all RDNs in B as its most general RDNs?
> - is there any sub-matching within a given RDN?  e.g.
>    CN="* Anderson" matching "CN="Anne Anderson", or some other
>    syntax for such partial matches?
> 
> Is there a standard for such comparisons?  An X500 ordering-rule
> or something?

X.509 (2000) says in section 8.4.2.2:

   If present, the permittedSubtrees and excludedSubtrees
   components each specify one or more naming subtrees, each
   defined by the name of the root of the subtree and, optionally,
   within that subtree, an area that is bounded by upper and/or
   lower levels. If permittedSubtrees is present, of all the
   certificates issued by the subject CA and subsequent CAs in the
   certification path, only those certificates with subject names
   within these subtrees are acceptable. If excludedSubtrees is
   present, any certificate issued by the subject CA or subsequent
   CAs in the certification path that has a subject name within
   these subtrees is unacceptable.

So, as you say, "A include all RDNs in B as its most general RDNs".

How are RDNs matched? X.520 has lots of information about that,
but RFC 3280 says you can do something much simpler:

   At a minimum, implementations MUST perform the DN comparison
   rules specified in Section 4.1.2.4.  CAs issuing certificates
   with a restriction of the form directoryName SHOULD NOT rely
   on implementation of the full ISO DN name comparison algorithm.

Neither X.520 nor section 4.1.2.4 of RFC 3280 provide for
wild-card matching within an attribute value, at least not
for any of the attributes normally included in a DN in a
certificate (those mentioned in section 4.1.2.4).

The name matching algorithm defined in section 4.1.2.4 of
RFC 3280 doesn't require any intelligent handling of Unicode
characters. X.520 doesn't do much better. There is an effort
underway to define better handling for such characters. But
at this point, section 4.1.2.4 is the rule for RFC 3280.

I hope that helps!

Steve Hanna

Date: Wed, 04 Sep 2002 15:39:34 -0400
From: Steve Hanna <[email-masked]>
To: "Housley, Russ" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: rfc822name Name Constraints question
Sender: [email-masked]

"Housley, Russ" wrote:
> The email address name constraint contains the right-hand part.
> So, any email address that exactly matches the right-hand part
> in the name constraint is valid.
> 
> >RFC3280 describes how name constraints for "Internet mail
> >addresses" may be specified, but is unclear on a few points:
> >
> >1. If the NameConstraint is "[email-masked]", does that include
> >    "[email-masked]"?
> 
> Yes.  The email address "[email-masked]" does satisfy the "[email-masked]"
> constraint.

I was surprised to see this answer. Here's the relevant text
from RFC 3280 (section 4.2.1.11):

   A name constraint for Internet mail addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example, "[email-masked]"
   indicates the root mailbox on the host "xyz.com".  To indicate all
   Internet mail addresses on a particular host, the constraint is
   specified as the host name.  For example, the constraint "xyz.com" is
   satisfied by any mail address at the host "xyz.com".  To specify any
   address within a domain, the constraint is specified with a leading
   period (as with URIs).  For example, ".xyz.com" indicates all the
   Internet mail addresses in the domain "xyz.com", but not Internet
   mail addresses on the host "xyz.com".

I see no indication here that a constraint of "[email-masked]"
would be satisfied by the address "[email-masked]". It seems
that the RFC describes three cases:

1) If the constraint is a complete mail address, then it is
   only satisfied by that mail address.

2) If the constraint is a host name, then it is satisfied by any
   mail address at that host.

3) If the constraint is a host name with a leading period, it is
   satisfied by any address within that domain.

If my analysis is correct, a constraint of "[email-masked]" is only
satisfied by "[email-masked]" (or anything that matches using
case-insensitive matching, since email addresses are case-insensitive).
There's no way to specify a constraint that would match exactly the set
of all email addresses that end in "[email-masked]".

The text of the RFC doesn't seem to support your assertion:
"The email address name constraint contains the right-hand part.
So, any email address that exactly matches the right-hand part in
the name constraint is valid."

> >2. Can "@xyz.com" be used to match all mail addresses at
> >    "xyz.com" but not addresses at "abc.xyz.com?
> 
> Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes (or
> .forward entries) on the host xyz.com.

Looking at the RFC, the interpretation of the mail address constraint
"@xyz.com" is not defined. It is neither a complete mail address, a
host name, nor a host name with a leading period. However, the constraint
"xyz.com" would accomplish Anne's goal here (matching all mail addresses
at the xyz.com but not addresses at abc.xyz.com).

> >3. The paragraph says the constraint "xyz.com" is satisfied by
> >    "any mail address at the host "xyz.com", and ".xyz.com" is
> >    satisfied by an address within the domain xyz.com, but not
> >    xyz.com itself.  How then do I specify all addresses in the
> >    domain xyz.com AND xyz.com itself?
> 
> The constraint "xyz.com" permits "[email-masked]" and "[email-masked]"

Not according to the RFC as I read it. The constraint "xyz.com"
only permits "[email-masked]" and "[email-masked]", not "[email-masked]".
If you want to specify a constraint that matches all of and only all of
the mail addresses on host xyz.com and all of the mail addresses in
the domain xyz.com, then you'd need to specify two constraint, one
being "xyz.com" and the other being ".xyz.com".

Please explain to me how your interpretation of the RFC is supported
by the text. I don't want to make a federal case out of this, but I
also don't want people to be confused by an erroneous interpretation
of the RFC. And if I'm wrong (or the RFC is wrong), I'd like to know
about it.

Thanks,

Steve Hanna

P.S. Anne did not ask me about her question before sending it, in case
you were wondering. I was on vacation last week.

Date: Wed, 4 Sep 2002 11:02:59 -0700
To: carol <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: BMP and UTF8
Sender: [email-masked]

At 11:14 AM +0800 8/23/02, carol wrote:
>    
>Hello everybody,
>
>    I'm looking for some Chinese characters that do not fall into BMP 
>but fall into UTF8.
>    Is there anyone who know such characters?

Please see the Unicode 3.1 or 3.2 standard. There are literally tens 
of thousands.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Marc Jadoul" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Wed, 4 Sep 2002 17:50:28 +0200
Sender: [email-masked]

Thanks Denis.
It is interresting.
I effectivelly think that for qualified cert and signature with a legal
value, CRL should be maintain during the same period than the validity
period of signatures. Thus archiving CRL for 20-30 years it not really
enought, we should also maintain them during this period: we should be able
to 'revoke' certs after expiration.
By adding Timestamping to PKI that was originaly foreseen for realtime
authentication, we add additional complexity and the original PKI design
show their limits. The Validity Period in a certificate means originally
that the certificate could be accepted in realtime during this Validity
Period. Thus it was logical to maintain CRLs only during this period. But
know that a certificate could be accepted long after his expiration,
revocation information should be maintain during the whole life of the
certificate. And the Validity Period of the certificate only concern the
time where the action is done, not anymore the time where the action is
verified.
May be we should have 2 Validity Period in the certificate: one for when the
cert can be used to sign and the other when the cert can be used for
verifying. Revocation Info should be maintain during the 2nd Validity Period
and not the first as today.
Best Regards,
Marc

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 04, 2002 2:46 PM
Subject: Re: Timestamping + Cert revocation + revocation question

>
> Marc,
>
> [Next time, please use text editing, instead of HTML editing]
>
> > Hi, I probably misunderstood something and I have a small question about
> > how to 'invalidate' a certificate that has already expired.
>
> Quite a strange formulation.
>
> > Here is a simple scenario:
>
> > User A get controle on a certificate certifying User B. It
> > create a signature in the name of user B. It then timestamp this
> > signature.Now User B do not know this. The certificate expire and it is
> > not possible to revoke it anymore (right?).
>
> RFC 3280 states:
>
>    An entry MUST NOT be removed from the CRL until it appears on one
>    regularly scheduled CRL issued beyond the revoked certificate's
>    validity period.
>
> This is a minimum condition.
>
> RFC 3125 states:
>
> B.8.3  Timing Constraints - Caution Period
>
>    Before an electronic signature may really be valid, the verifier has
>    to be sure that the holder of the private key was really the only one
>    in possession of key at the time of signing.  However, there is an
>    inevitable delay between a compromise or loss of key being noted, and
>    a report of revocation being distributed.  To allow greater
>    confidence in the validity of a signature, a "cautionary period" may
>    be identified before a signature may be said to be valid with high
>    confidence.  A verifier may revalidate a signature after this
>    cautionary signature, or wait for this period before validating a
>    signature. The validation policy may specify such a cautionary period.
>
> This would mean that the CA should continue, at least, to make available
> the revocation status information until the end of the cautionnary period.
> However, there are two problems:
>
>   1) the CA is ignorant about the duration of the various cautionary
>      periods from the various signature/validation policies.
>
>   2) unless using the CPS, the CA has no way to indicate how long after
>      the end of the certificate validity period, it will maintain the
>      revocation status information ... and the CPS is not directly machine
>      processable.
>
> > The time-stamped signature is
> > thus valid and I do not know any mean to communicate that the
certificate
> > was wrong from the begining. Any relying party will continue to accept
the
> > time-stamped signature, even if User B and the CA now know the there was
a
> > problem with the certificate at the time of the signature.
>
> Whether or not the certificate has expired, a user who does not know that
> his private key has been compromised may be issuing "valid" signatures
> without knowing it.
>
> In a CRL, it is possible to include an invalidity date that provides the
> date on which it is known or suspected that the private key was
compromised.
> This date may be earlier than the revocation date in the CRL entry.
>
> However, any CRL fetched soon after the cautionary period is sufficient to
> prove that the signature was valid. So a fresher CRL would not
> help to declare the signature invalid if it is issued after the end of the
> cautionary period. The only advantage would be that the CA would have an
> information about a user declaration of an invalidity date, maybe sooner
> than the time included in the time-stamp token.
>
> > Does it exist
> > some way to communicate that a certificate was invalid from a specific
> > date, even if it is known only after expiration of the certificate? How
to
> > invalidate a timestamped signature?
>
> You seem to be looking for a user declaration of an invalidity date and
> since the CA will not care about an expired certificate, you wonder where
> and how this declaration could be done.
>
> There are two possible answers to your question:
>
> 1) Extend the time period during which the revocation information is
>    both handled and maintained and indicate the end of that period using
>    a new (non-critical) CRL extension. That time should be superior to the
>    cautionary period from the signature policy or the validation policy.
>    This would cover the cautionary period.
>
> 2) Beyond the end of the cautionary period, since anyway this declaration
>    will not be "visible" in the CRL used to validate the signature
>    (and picked during the cautionary period), it does not matter where
that
>    declaration will be made. Today someone having his car robbed will make
>    a declaration of robbery to the police. The same happens with door
keys.
>    Maybe, in the future, some people will make a declaration of loss for
>    a private key to the police.
>
> Regards,
>
> Denis
>
> > In the real world you would destroy it but here, it can perfectly be
duplicated.
> > Marc Jadoul

Date: Wed, 04 Sep 2002 15:12:12 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Steve Tuecke <[email-masked]>
CC: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve,

> Denis,

Since my first name appears at the top of this very loooong e-mail, 
I feel forced to reply.

> PKIX has already influenced the content of the proxy cert profile
> substantially.  I realized after my last email that "languished" was
> perhaps a poor choice of words.  In fact, the document has progressed
> substantially since its initial submission, based in part upon discussions
> with several PKIX participants.  It would perhaps be better to describe it
> as "languishing" (present tense), as it seems that changes have reached a
> plateau, with no clear path or energy to move it forward in PKIX.  (Though
> maybe this discussion will change that.)
> 
> The document is definitely still influenceable, if people are willing to
> expend the effort to attempt to influence it in the near future.  

Fine. This clarifies the issue that I raised.

> The
> document has evolved substantially during the year and a half it has been
> out there, such that the authors are now pretty happy with it.  But
> frankly, there really is not all that much to this profile. (See
> below.)  If there is acceptance of the fundamental approach of having a
> proxy cert signed by an end-entity cert or another proxy cert, then I think
> reaching consensus on the details should not be hard or take very long
> given the progress we have already made.
> 
> But that is where I see that the problem lies.  As I mentioned in my
> previous emails, we have also had conversations with PKIX people that led
> to my belief that there may we irreconcilable differences of opinion about
> this approach.  There are those who apparently believe that the approach is
> fundamentally at odds with X.509 and PKIX world views, and should not be
> sanctioned.
> 
> Perhaps this is the straw poll that needs to be taken...

I do not have that kind of problem as long as the draft is using everywhere
"proxy certificate" and is NOT using the terminology "public key
certificate".

RFC 3280 is about a public key certificate, as mentioned in some text
extracted from RFC 3280 below:

   Users of a public key require confidence that the associated private
   key is owned by the correct remote subject (person or system) with
   which an encryption or digital signature mechanism will be used.
   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  

As far as ASN.1 is concerned since the issuer field identifies "the entity
who has signed and issued the certificate", there is no problem as well.  

> Should PKIX sanction the advancement of a proxy cert draft based on the
> current fundamental approach?  We can argue about the details more later,
> but the fundamental approach at issue is whether it is reasonable to use
> end-entity public key certificates to sign proxy certificates. Possible
> answers are:
>    1) No.
>    2) Yes, but only as Informational Track.
>    3) Yes, as Standards Track.
> 
> In order better inform voters, it is perhaps useful for me to summarize the
> approach, and some of the discussions that have occurred.  Note that I have
> purposely omitted names in the following text.  As none of the referenced
> discussions with PKIX people happened in a public forum, I don't want to
> drag them into a public debate against their will.  But of course, I'm
> happy if they jump in and take credit for (and argue for) the suggestions
> and critiques describe below.
> 
> A proxy cert is denoted by the presence of the proxyCertInfo extension,
> which must be marked critical.  

Compliant software SHALL then reject such a certificate, if that extension
is present and they do not know how to process it. 

> A proxy cert is signed/issued by either an end-entity cert, 

Fine.
 
> or by another proxy cert.  

This may be much more complicated to handle.

> The subject of the proxy cert
> is derived from that of its issuer, by taking the issuer DN and appending a
> common name whose value should be unique amongst all proxy certs issued by
> a particular issuer.  

> The subjectAltName must be empty, and there are rules
> for what is allowed in the proxy cert's key usage and extended key usage
> relative to its issuer.
 
> The proxyCertInfo extension carries three things: a version number, so more
> info can be added to it in a subsequent revision, if desired; a
> pCPathLenConstraint to limit the proxy path length; and a proxyPolicy that
> is just a 2-tuple containing an OID of a policy language, and a policy blob
> expressed in that language.  There are two simple policies defined in the
> draft: one that states that the proxy cert is allowed to impersonate its
> issuer (that is, it inherits all rights that the issuer has), and one that
> states that the proxy cert is independent of its issuer (that is, it
> inherits no rights from its issuer).  Other policy languages can be defined
> that allow for finer grain inheritance of rights from the issuer.

My own belief is that impersonation only is VERY dangerous and thus I see
little value for that draft, unless the target(s) where the proxy
certificate can be used can be restricted. So I am NOT talking about a finer 
grain inheritance of rights from the issuer (which would be useful as well) 
but about a finer grain of usage of the rights from the issuer (which may 
simply be its identity).
 
> Changes are required to the path validation algorithm, in order to verify
> that the proxy subject is properly derived from the subject of its issuer,
> to verify the key usage and extended key usage are correctly derived from
> the issuer, and to check the pCPathLenConstraint.

Maybe this is where we have a problem. This is not a *change* in the path
validation algorithm, but this should be an *addition* to the basic path
validation algorithm to say how to process the proxy certificate(s).

> That's about it.
> 
> The biggest change to the draft came with the -02 version.  Based on
> discussions and suggestions from PKIX members, we changed the way subject
> names were handled in proxies, in order to make them work better with
> attribute certificates.  Prior to that version, we went to some length to
> avoid providing a useful proxy subject, so that a proxy really just
> inherited its name from its issuing end-entity cert.  In other words, it
> was more of a straight impersonation approach -- in essence, we were
> basically just binding temporary keys to an existing end-entity
> subject.  This changed to the approach described above, in which each proxy
> cert is given a unique subject DN, derived from that of its issuer.  This
> allows a proxy cert to be the holder of an attribute cert.

 ... but this complicates even more the design.

> The concern that has been expressed by various PKIX people is that we are
> using end-entity certs to issue proxy certs.  The argument is that we are
> using the end-entity cert like a CA cert, which violates the fundamental
> X.509 and PKIX world view.

Not really. If there is no basic constraints extension field in the proxy
certificate, then there cannot be any violation. 
 
> At some conceptual level, this is obviously true -- we are creating a key
> pair, creating a unique subject name, and then using the end-entity cert to
> sign a certificate containing the public key, name, and other information
> including the proxyCertInfo.  However:
> 
>    1) A proxy certificate is not an end-entity certificate -- a proxy
> cert's reason for existing is quite different from an end-entity cert.  The
> whole point of proxy certs is to allow for relatively short-lived entities,
> which are dynamically created and destroyed, to be given an authenticatable
> identity, optionally accompanied with some delegated rights from the
> issuer.  Issuing certificates using a traditional CA model is not practical
> or efficient for such entities.
> 
>    2) Existing code that does not implement proxy cert path validation will
> reject a proxy cert that is presented to it for 2 reasons: (1) the
> BasicConstraints.cA bit of the issuing end-entity is false, and (2) the
> proxyCertInfo extension is marked critical.  So unless existing code is
> horribly mis-implemented (even these most basic checks are not done in its
> path validation), there should be no concern about problems that proxy
> certs can cause to existing implementations.
> 
>    3) Code that properly implements proxy cert path validation cannot
> confuse an end-entity cert with a proxy cert.  The proxy cert path
> validation will reject an end-entity cert signed by a proxy cert, or a
> proxy cert that tries to spoof some subject name that is not properly
> derived from that of the issuing end-entity.  So in new code that
> implements proxy cert's, there is clear delineation between the two.
> 
> So while at some level an end-entity and proxy cert look a lot alike, they
> are really distinct things, used for distinct purposes, and cannot be
> confused with each other either by an existing implementation that does not
> implement the proxy cert profile, or by a new implementation that properly
> implements the proxy cert profile.
> 
> The only alternative approaches that were suggested were:
> 
>    A) Have existing CAs issue end-entity certificates with the
> BasicConstraints.cA bit set to true, 

No. This violates X.509.

> and name constraints set to restrict
> the subjects of any certs signed by that end-entity.  In other words,
> instead of issuing end-entity certs, issue subordinate CA certs.  An
> advantage to this approach is that it lives within the current X.509/PKIX
> model.  But I believe this approach has a few problems.  First, of the CA
> operators I have talked to, none of them would issue "end-entity" certs
> with the cA bit set to true, as they found that even more counter to the
> X.509/PKIX world view than the introduction of proxy certs.  Second, many
> existing implementations do not implement name constraints, which not only
> means new code would need to be rolled out anyway (just like it does for
> proxies), but that existing code could easily be spoofed by an end-entity
> that signs another end-entity subject.  On this last point, an advantage to
> the current proxy cert profile is that code that has not been explicitly
> coded to accept proxies will reject them due to the existing fundamental
> path validation rules.
> 
>    B) Create an CA which automatically issues new end-entity certs on
> demand for the dynamically created entities.  

No. This violates X.509.

> The primary problem with this
> approach is scalability, particularly in a large, widely distributed system
> with lots of dynamically created entities (which is exactly what we are
> building today in various Grid applications using proxy certs).  The
> advantage of the current proxy cert profile is that a proxy can be
> unilaterally created by an existing entity (the holder of an end-entity
> cert or existing proxy cert), with no need for centralization.
> 
>    C) Forget X.509, and just use raw keys for what we are trying to
> do.  But the reason we went down the proxy cert path in the first place was
> so that they could drop into existing code base (e.g. SSL/TLS libraries)
> with little modification.  

Once again, this is where the issue lies. What would be "existing code base
with little modification" ? You could *add* some code to handle proxy
certificates. 

> Technical details aside, I also found this
> argument to be curious coming from a PKIX person -- given that PKIX
> specifications as they exist today do not meet our needs, does it make more
> sense to augment the current PKIX specifications as we have done, or is it
> better to just bail on X.509 entirely?

The middle issue is to use existing code for public key certificates and 
*add* to it the handling of proxy certificates. Would this be infeasible ?

Denis

PS: Thank you for this very detailed and very clear summary, but next time,
try to make the e-mail shorter.

> -Steve
> 
> At 02:58 AM 8/30/2002, Denis Pinkas wrote:
> >Russ,
> >
> > > Steve:
> > >
> > > I think that a straw poll is in order.  If the consensus of the group is
> > > that this work should proceed, then we simply follow the usual process.  If
> > > the consensus of the group is that this work should not proceed, then
> > > withdrawal is the appropriate course of action.
> > >
> > > Would the PKIX WG Chairs please conduct the poll...
> >
> >Hold on a second.
> >
> >Is this document going to follow the Standards Track or the Informational
> >Track ?
> >
> >I understood that the document is being progressed in the Grid Forum
> >Document and is well advanced. I wonder if the PKIX WG will have the real
> >possiblity to influence the content of the document. When a document is
> >going on the Standards Track, it has to reflect the consensus of the PKIX
> >WG and we all know by experience that it takes much more than a couple of
> >months to reach a consensus. I wonder if that time frame is compatible with
> >the goals of the people supporting that document.
> >
> >Now, if the document is going to follow the Informational Track, it can do
> >it within or outside the PKIX WG.
> >
> >Before any strow poll is conducted, it first needs to be clarified whether
> >the proposal would be to carry on the work on the Standards Track or the
> >Informational Track.
> >
> >Denis
> >
> > > Russ
> > >
> > > At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
> > > >Russ,
> > > >
> > > >So how do we get there from here?
> > > >
> > > >One fundamental obstacle may be that there are some PKIX participants who
> > > >seem to be fundamentally opposed to the approach taken in the proxy cert
> > > >profile.  Having had a number of conversations with such people, my belief
> > > >is that it is likely an irreconcilable difference.  It seems to be more of
> > > >a difference in world-view than in any specific technical detail -- they
> > > >believe that using an end-entity certificate to sign proxy certificates is
> > > >at fundamental odds with X.509 and PKIX philosophies.
> > > >
> > > >But even if we are able to resolve this difference (e.g. either through
> > > >finding an approach that we all agree on, or by agreeing to disagree but
> > > >moving forward anyway), I guess its not clear to me how we overcome the
> > > >energy barrier to advance it to an RFC.  There seems to be a general
> > > >apathy within PKIX participants toward advancing this draft.  (And please
> > > >realize that I am not faulting anybody by making this statement.  We all
> > > >have our own agendas within PKIX, and it may just be that mine is too far
> > > >off the radar for most.)
> > > >
> > > >I'm completely comfortable with PKIX making a consensus decision that the
> > > >Proxy Cert Profile should not be considered further in PKIX.  I'm also
> > > >happy to push forward with it if there is support for doing so.  But given
> > > >that it is currently languishing in PKIX, and that I don't see an obvious
> > > >path toward reaching consensus in PKIX on this profile, I felt the most
> > > >reasonable route was to suggest the withdrawal of the draft from PKIX.
> > > >
> > > >-Steve
> > > >
> > > >At 02:57 PM 8/27/2002, Housley, Russ wrote:
> > > >>Steve:
> > > >>
> > > >>I would like to see certificate handling libraries support the delegation
> > > >>environment, and the people that write such libraries are currently
> > > >>paying attention to the PKIX WG.  So, that is my preferred route.
> > > >>
> > > >>Russ
> > > >>
> > > >>At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
> > > >>>Russ,
> > > >>>
> > > >>>There are, of course, two avenues to RFC -- one through a working group,
> > > >>>and the other as an individual submission.  I am curious what you think
> > > >>>of each of these avenues, and more generally why you would prefer to see
> > > >>>it published as an RFC.  For broad acceptability of the profile, the
> > > >>>best route is obviously PKIX.  But if that doesn't happen, is there any
> > > >>>value to it being an individually submitted informational RFC, in
> > > >>>addition to a GGF (RFC-like) GFD?  (The GGF document process is pretty
> > > >>>similar to IETF.)
> > > >>>
> > > >>>-Steve
> > > >>>
> > > >>>At 01:01 PM 8/27/2002, Housley, Russ wrote:
> > > >>>>Steve:
> > > >>>>
> > > >>>>I understand the need for you to make progress.  And, I will support
> > > >>>>any pragmatic decision that you make.  However, I would prefer to see
> > > >>>>this profile published as an RFC.
> > > >>>>
> > > >>>>Russ
> > > >>>>
> > > >>>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
> > > >>>>
> > > >>>>>All,
> > > >>>>>
> > > >>>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key
> > > >>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02)
> > > >>>>>and introduced it into the Global Grid Forum (GGF, www.gridforum.org).
> > > >>>>>Shortly after that, because it seemed to relate to the work in PKIX,
> > > >>>>>we also introduced it into the PKIX working group.  Tim and Steve
> > > >>>>>accepted this draft into PKIX and gave me time at several IETFs to
> > > >>>>>present progress on this draft (for which we are most grateful!),
> > > >>>>>which led to many useful discussions with IETF folks.  Over the past
> > > >>>>>year and a half, we have continued to refine the draft as a result of
> > > >>>>>this input and our own continuing work in this area.
> > > >>>>>
> > > >>>>>We are now trying to reach closure on this draft, so that various
> > > >>>>>groups, including our Globus Project, can implement and deploy to a
> > > >>>>>non-moving target.  There is strong support in the GGF Grid Security
> > > >>>>>Infrastructure (GSI) working group to finalize the draft, and push it
> > > >>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent of
> > > >>>>>an RFC. However, within the PKIX community I think its fair to say
> > > >>>>>that it has received little attention, and the reactions that have
> > > >>>>>been expressed have been mixed -- everywhere from strong disagreement
> > > >>>>>to strong support of the approach.
> > > >>>>>
> > > >>>>>We have a new, significantly cleaned up draft available at
> > > >>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet
> > > >>>>>submitted it to IETF, pending the outcome of this discussion.
> > > >>>>>
> > > >>>>>Our current intention is to withdraw this document from PKIX
> > > >>>>>consideration, and finish it up within GGF.  (The previous
> > > >>>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a
> > > >>>>>public ground swell to complete it within PKIX, we are happy to
> > reconsider.
> > > >>>>>
> > > >>>>>Meanwhile, this draft is currently in last-call in the GGF GSI working
> > > >>>>>group, prior to submitting it for consideration to become a GFD.  We
> > > >>>>>would be happy to receive and incorporate feedback to the latest GGF
> > > >>>>>draft (see above URL), prior to the final submission (hopefully within
> > > >>>>>in a couple weeks).
> > > >>>>>
> > > >>>>>Thanks,
> > > >>>>>-Steve
> > > >>>>>-------------------------------------------------------------------
> > -----
> > > >>>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630)
> > 252-8711
> > > >>>>>[email-masked]     Argonne National Laboratory  cell: (630)
> > 842-6917
> > > >>>>>http://www.mcs.anl.gov/~tuecke Argonne, IL 60439   fax: (630) 252-5986

Date: Wed, 04 Sep 2002 14:46:39 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Marc Jadoul <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamping + Cert revocation + revocation question
Sender: [email-masked]

Marc,

[Next time, please use text editing, instead of HTML editing]

> Hi, I probably misunderstood something and I have a small question about
> how to 'invalidate' a certificate that has already expired.

Quite a strange formulation.

> Here is a simple scenario:

> User A get controle on a certificate certifying User B. It
> create a signature in the name of user B. It then timestamp this
> signature.Now User B do not know this. The certificate expire and it is
> not possible to revoke it anymore (right?).

RFC 3280 states:

   An entry MUST NOT be removed from the CRL until it appears on one 
   regularly scheduled CRL issued beyond the revoked certificate's 
   validity period.

This is a minimum condition. 

RFC 3125 states:

B.8.3  Timing Constraints - Caution Period

   Before an electronic signature may really be valid, the verifier has
   to be sure that the holder of the private key was really the only one
   in possession of key at the time of signing.  However, there is an
   inevitable delay between a compromise or loss of key being noted, and
   a report of revocation being distributed.  To allow greater
   confidence in the validity of a signature, a "cautionary period" may
   be identified before a signature may be said to be valid with high
   confidence.  A verifier may revalidate a signature after this
   cautionary signature, or wait for this period before validating a
   signature. The validation policy may specify such a cautionary period.

This would mean that the CA should continue, at least, to make available
the revocation status information until the end of the cautionnary period.
However, there are two problems:

  1) the CA is ignorant about the duration of the various cautionary
     periods from the various signature/validation policies.  
  
  2) unless using the CPS, the CA has no way to indicate how long after 
     the end of the certificate validity period, it will maintain the 
     revocation status information ... and the CPS is not directly machine 
     processable.

> The time-stamped signature is
> thus valid and I do not know any mean to communicate that the certificate
> was wrong from the begining. Any relying party will continue to accept the
> time-stamped signature, even if User B and the CA now know the there was a
> problem with the certificate at the time of the signature.

Whether or not the certificate has expired, a user who does not know that
his private key has been compromised may be issuing "valid" signatures
without knowing it.

In a CRL, it is possible to include an invalidity date that provides the
date on which it is known or suspected that the private key was compromised.
This date may be earlier than the revocation date in the CRL entry.
 
However, any CRL fetched soon after the cautionary period is sufficient to
prove that the signature was valid. So a fresher CRL would not
help to declare the signature invalid if it is issued after the end of the
cautionary period. The only advantage would be that the CA would have an
information about a user declaration of an invalidity date, maybe sooner
than the time included in the time-stamp token.

> Does it exist
> some way to communicate that a certificate was invalid from a specific
> date, even if it is known only after expiration of the certificate? How to
> invalidate a timestamped signature? 

You seem to be looking for a user declaration of an invalidity date and
since the CA will not care about an expired certificate, you wonder where
and how this declaration could be done.

There are two possible answers to your question:

1) Extend the time period during which the revocation information is
   both handled and maintained and indicate the end of that period using 
   a new (non-critical) CRL extension. That time should be superior to the 
   cautionary period from the signature policy or the validation policy. 
   This would cover the cautionary period.

2) Beyond the end of the cautionary period, since anyway this declaration 
   will not be "visible" in the CRL used to validate the signature 
   (and picked during the cautionary period), it does not matter where that 
   declaration will be made. Today someone having his car robbed will make 
   a declaration of robbery to the police. The same happens with door keys. 
   Maybe, in the future, some people will make a declaration of loss for 
   a private key to the police.

Regards,

Denis

> In the real world you would destroy it but here, it can perfectly be duplicated. 

> Marc Jadoul

From: "Marc Jadoul" <[email-masked]>
To: "Esposito Alfredo" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Timestamping + Cert revocation + revocation question
Date: Wed, 4 Sep 2002 14:39:45 +0200
Sender: [email-masked]

Hi,

Yes I agree with you, User B can apply to the court. He might win, and the
court might decide that any signature made with this key/cert after a
defined date is invalid.
But what seems wrong to me is that there is no technical way (like CRL for
expired certs) to communicate to any third party this fact and any one will
continue to accept signature made with this key/cert because the (expired)
cert can not be revoked anymore.

Marc Jadoul
----- Original Message -----
From: "Esposito Alfredo" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>
Sent: Wednesday, September 04, 2002 11:22 AM
Subject: Re: Timestamping + Cert revocation + revocation question

> Hi
> that is something weird in your scenario. In order to sign a document
> user A should control the private key of user B. The certificate alone
> is not enough to sign anything. In the legal system of  the countries
> introducing digital signature, the revocation status applies after the
> publication of a CRL. Before this publication user B can not repudiate
> his signature. Of course, User B can apply to the court. Depending on
> the kind of storing the private key (smart card, floppy, hard disk...)
> and all the other factors, the court will decide about the legal
> effects of the claimed forged signature.
>
> Alfredo Esposito
> InfoCamere SCpA
> Digital Signature
> Via Morgagni 30H
> 00161 Roma
> Italy
>
>
> Marc Jadoul wrote:
>
> > Hi,
> >
> >
> >
> > I probably misunderstood something and I have a small question about
> > how to 'invalidate' a certificate that has already expired.
> >
> > Here is a simple scenario:
> >
> > User A get controle on a certificate certifying User B. It create a
> > signature in the name of user B. It then timestamp this signature.
> >
> > Now User B do not know this. The certificate expire and it is not
> > possible to revoke it anymore (right?).
> >
> > The time-stamped signature is thus valid and I do not know any mean to
> > communicate that the certificate was wrong from the begining. Any
> > relying party will continue to accept the time-stamped signature, even
> > if User B and the CA now know the there was a problem with the
> > certificate at the time of the signature.
> >
> > Does it exist some way to communicate that a certificate was invalid
> > from a specific date, even if it is known only after expiration of the
> > certificate?
> >
> >
> >
> > How to invalidate a timestamped signature? In the real world you would
> > destroy it but here, it can perfectly be duplicated.
> >
> >
> >
> > Marc Jadoul
> >
>
>
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-04.txt
Date: Wed, 04 Sep 2002 07:57:18 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-04.txt
	Pages		: 19
	Date		: 2002-9-3
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [email-masked]
mailing list.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-04.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 23 Aug 2002 11:14:42 +0800
From: carol <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: BMP and UTF8
Sender: [email-masked]

Hello everybody,

   I'm looking for some Chinese characters that do not fall into BMP but fall into UTF8.
   Is there anyone who know such characters?

   Thanks a lot for any answer.

carol

Date: Tue, 03 Sep 2002 18:31:11 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

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

Steve Tuecke wrote:
>    2) Existing code that does not implement proxy cert path validation will
> reject a proxy cert that is presented to it for 2 reasons: (1) the
> BasicConstraints.cA bit of the issuing end-entity is false, and (2) the
> proxyCertInfo extension is marked critical.  So unless existing code is
> horribly mis-implemented (even these most basic checks are not done in its
> path validation), there should be no concern about problems that proxy
> certs can cause to existing implementations.

But remember that MSIE's certificate checking *is* horribly mis-implemented.
Of course this doesn't lead to a security problem that is not already present
in MSIE, but it could lead to significant user confusion (because a proxy cert
looks to the user exactly like an attempted exploit of the BasicConstraints
checking bug).

Would the critical proxyCertInfo extension cause MSIE to reject proxy certs?

- -- 
David Hopwood <[email-masked]>

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

From: "Housley, Russ" <[email-masked]>
To: Steve Tuecke <[email-masked]>
Cc: [email-masked]
Date: Tue, 03 Sep 2002 09:54:00 -0400
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Sender: [email-masked]

Steve:

>Should PKIX sanction the advancement of a proxy cert draft based on the 
>current fundamental approach?  We can argue about the details more later, 
>but the fundamental approach at issue is whether it is reasonable to use 
>end-entity public key certificates to sign proxy certificates. Possible 
>answers are:
>   1) No.
>   2) Yes, but only as Informational Track.
>   3) Yes, as Standards Track.

I would vote for 3.  I think that the inclusion of a critical extension in 
proxy certificates is key.  This extension keeps proxy certificates from 
being confused with other CA certificates.

Russ

From: "Marc Jadoul" <[email-masked]>
To: <[email-masked]>
Subject: Timestamping -> Cert expiration -> Cert 'revocation' ??
Date: Tue, 3 Sep 2002 15:23:45 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C2535D.E4932E30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry to annoy everybody. The original subject was wrong, and I suppose =
that I need to correct it if I want a response :-/
Marc
  ----- Original Message -----=20
  From: Marc Jadoul=20
  To: [email-masked]=20
  Sent: Tuesday, September 03, 2002 12:55 PM
  Subject: Timestamping + Cert revocation + revocation question

  Hi,

  I probably misunderstood something and I have a small question about =
how to 'invalidate' a certificate that has already expired.
  Here is a simple scenario:
  User A get controle on a certificate certifying User B. It create a =
signature in the name of user B. It then timestamp this signature.
  Now User B do not know this. The certificate expire and it is not =
possible to revoke it anymore (right?).
  The time-stamped signature is thus valid and I do not know any mean to =
communicate that the certificate was wrong from the begining. Any =
relying party will continue to accept the time-stamped signature, even =
if User B and the CA now know the there was a problem with the =
certificate at the time of the signature.
  Does it exist some way to communicate that a certificate was invalid =
from a specific date, even if it is known only after expiration of the =
certificate?

  How to invalidate a timestamped signature? In the real world you would =
destroy it but here, it can perfectly be duplicated.

  Marc Jadoul

------=_NextPart_000_002E_01C2535D.E4932E30
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Sorry to annoy everybody. The original=20
subject&nbsp;was wrong, and&nbsp;I suppose that&nbsp;I need to correct =
it=20
if&nbsp;I want a response :-/</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Marc</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] =
href=3D"mailto:[email-masked]">Marc=20
  Jadoul</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 03, =
2002 12:55=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Timestamping + Cert =
revocation +=20
  revocation question</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I probably misunderstood something =
and I have a=20
  small question about how to 'invalidate' a certificate that has =
already=20
  expired.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Here is a simple =
scenario:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>User A get controle on a certificate =
certifying=20
  User B. It create a signature in the name of user B. It then timestamp =
this=20
  signature.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Now User&nbsp;B&nbsp;do not&nbsp;know =
this. The=20
  certificate expire and it is not possible to revoke it anymore=20
  (right?).</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>The time-stamped signature is thus =
valid=20
  and&nbsp;I do not know any mean to communicate that the certificate =
was wrong=20
  from the begining. Any relying party will continue to accept the =
time-stamped=20
  signature, even if User B and the CA now know the there was a problem =
with the=20
  certificate at the time of the signature.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Does it&nbsp;exist some way to =
communicate that a=20
  certificate was invalid from a specific date, even if it is&nbsp;known =

  only&nbsp;after expiration of the certificate?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>How to invalidate a timestamped =
signature? In the=20
  real world you would destroy it but here, it can perfectly be=20
  duplicated.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Marc =
Jadoul</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002E_01C2535D.E4932E30--

Content-return: allowed
Date: Tue, 03 Sep 2002 06:09:19 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
To: "'Steve Tuecke '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.

--Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)
Content-type: text/plain

Linn and Kent directed IETF towards an Internet PKI
based on organizational affiliation; records show that
considerable effort since 1987 has been put into denying 
users (in  PEM/PKIX worlds) the ability to act as certificate 
issuers.

Read RFC 1040/1113, and its clear that Steve at least
concedes that X.509 permits users to be CAs. The documents
are clear that part of the (old) motivation for
the limitations PEM/PKIX still places on the X.509
model were to do with the historical need to 
to flow revenues to a patent licensee, per-certificate. 
Organizational certification supported that goal, which
was important to the Internet PKI at the time. Its very
hard to deny the legitimacy of either model, note: 1040 
re-emerged as the wildy successful VeriSign Onsite, and 
1422's ON model is still in vouge in  US/CA military 
messaging infrastructures.

In terms of consensus, I doubt we can obtain any
on this issue in IETF. There are simply two worlds: the world
of the philosophy of PKIX, and reality of actual needs and 
legacy support. Both world views are convincing and laudable; convergence is
unlikely. Matters of policy and application really
dont need PKIX WG involvement, however. All the commodity
software out there is entirely customisable in the
field, and vendor-working groups are probably a better
forum than PKIX - which properly concentrates on leading,
if not fulfilling, the long term infrastructure vision.

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

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that
led 
to my belief that there may we irreconcilable differences of opinion
about 
this approach.  There are those who apparently believe that the approach
is 
fundamentally at odds with X.509 and PKIX world views, and should not be

sanctioned.

--Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)
Content-type: text/html
Content-transfer-encoding: quoted-printable

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

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Linn and Kent directed IETF towards an Internet =
PKI</FONT>
<BR><FONT SIZE=3D2>based on organizational affiliation; records show =
that</FONT>
<BR><FONT SIZE=3D2>considerable effort since 1987 has been put into =
denying </FONT>
<BR><FONT SIZE=3D2>users (in&nbsp; PEM/PKIX worlds) the ability to act =
as certificate </FONT>
<BR><FONT SIZE=3D2>issuers.</FONT>
</P>

<P><FONT SIZE=3D2>Read RFC 1040/1113, and its clear that Steve at =
least</FONT>
<BR><FONT SIZE=3D2>concedes that X.509 permits users to be CAs. The =
documents</FONT>
<BR><FONT SIZE=3D2>are clear that part of the (old) motivation =
for</FONT>
<BR><FONT SIZE=3D2>the limitations PEM/PKIX still places on the =
X.509</FONT>
<BR><FONT SIZE=3D2>model were to do with the historical need to </FONT>
<BR><FONT SIZE=3D2>to flow revenues to a patent licensee, =
per-certificate. </FONT>
<BR><FONT SIZE=3D2>Organizational certification supported that goal, =
which</FONT>
<BR><FONT SIZE=3D2>was important to the Internet PKI at the time. Its =
very</FONT>
<BR><FONT SIZE=3D2>hard to deny the legitimacy of either model, note: =
1040 </FONT>
<BR><FONT SIZE=3D2>re-emerged as the wildy successful VeriSign Onsite, =
and </FONT>
<BR><FONT SIZE=3D2>1422's ON model is still in vouge in&nbsp; US/CA =
military </FONT>
<BR><FONT SIZE=3D2>messaging infrastructures.</FONT>
</P>

<P><FONT SIZE=3D2>In terms of consensus, I doubt we can obtain =
any</FONT>
<BR><FONT SIZE=3D2>on this issue in IETF. There are simply two worlds: =
the world</FONT>
<BR><FONT SIZE=3D2>of the philosophy of PKIX, and reality of actual =
needs and </FONT>
<BR><FONT SIZE=3D2>legacy support. Both world views are convincing and =
laudable; convergence is&nbsp; unlikely. Matters of policy and =
application really</FONT></P>

<P><FONT SIZE=3D2>dont need PKIX WG involvement, however. All the =
commodity</FONT>
<BR><FONT SIZE=3D2>software out there is entirely customisable in =
the</FONT>
<BR><FONT SIZE=3D2>field, and vendor-working groups are probably a =
better</FONT>
<BR><FONT SIZE=3D2>forum than PKIX - which properly concentrates on =
leading,</FONT>
<BR><FONT SIZE=3D2>if not fulfilling, the long term infrastructure =
vision.</FONT>
</P>

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

<P><FONT SIZE=3D2>But that is where I see that the problem lies.&nbsp; =
As I mentioned in my </FONT>
<BR><FONT SIZE=3D2>previous emails, we have also had conversations with =
PKIX people that</FONT>
<BR><FONT SIZE=3D2>led </FONT>
<BR><FONT SIZE=3D2>to my belief that there may we irreconcilable =
differences of opinion</FONT>
<BR><FONT SIZE=3D2>about </FONT>
<BR><FONT SIZE=3D2>this approach.&nbsp; There are those who apparently =
believe that the approach</FONT>
<BR><FONT SIZE=3D2>is </FONT>
<BR><FONT SIZE=3D2>fundamentally at odds with X.509 and PKIX world =
views, and should not be</FONT>
</P>

<P><FONT SIZE=3D2>sanctioned.</FONT>
<BR><FONT SIZE=3D2></FONT>&nbsp;
</P>

</BODY>
</HTML>

--Boundary_(ID_ClkxhhEQPd5BoP616Vl8Og)--

Content-return: allowed
Date: Tue, 03 Sep 2002 06:08:23 -0700
From: Peter Williams <[email-masked]>
Subject: RE: Withdrawl of Proxy Cert Profile draft from PKIX
To: "'Steve Tuecke '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.

--Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)
Content-type: text/plain

Linn and Kent directed IETF towards an Internet PKI
based on organizational affiliation; records show that
considerable effort since 1987 has been put into denying 
users (in  PEM/PKIX worlds) the ability to act as certificate 
issuers.

Read RFC 1040/1113, and its clear that Steve at least
concedes that X.509 permits users to be CAs. The documents
are clear that part of the (old) motivation for
the limitations PEM/PKIX still places on the X.509
model were to do with the historical need to 
to flow revenues to a patent licensee, per-certificate. 
Organizational certification supported that goal, which
was important to the Internet PKI at the time. Its very
hard to deny the legitimacy of either model, note: 1040 
re-emerged as the wildy successful VeriSign Onsite, and 
1422's ON model is still in vouge in  US/CA military 
messaging infrastructures.

In terms of consensus, I doubt we can obtain any
on this issue in IETF. There are simply two worlds: the world
of the philosophy of PKIX, and reality of actual needs and 
legacy support. Both world views are convincing and laudable; convergence is
unlikely. Matters of policy and application really
dont need PKIX WG involvement, however. All the commodity
software out there is entirely customisable in the
field, and vendor-working groups are probably a better
forum than PKIX - which properly concentrates on leading,
if not fulfilling, the long term infrastructure vision.

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

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that
led 
to my belief that there may we irreconcilable differences of opinion
about 
this approach.  There are those who apparently believe that the approach
is 
fundamentally at odds with X.509 and PKIX world views, and should not be

sanctioned.

--Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)
Content-type: text/html
Content-transfer-encoding: quoted-printable

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

<P><FONT SIZE=3D2>Linn and Kent directed IETF towards an Internet =
PKI</FONT>
<BR><FONT SIZE=3D2>based on organizational affiliation; records show =
that</FONT>
<BR><FONT SIZE=3D2>considerable effort since 1987 has been put into =
denying </FONT>
<BR><FONT SIZE=3D2>users (in&nbsp; PEM/PKIX worlds) the ability to act =
as certificate </FONT>
<BR><FONT SIZE=3D2>issuers.</FONT>
</P>

<P><FONT SIZE=3D2>Read RFC 1040/1113, and its clear that Steve at =
least</FONT>
<BR><FONT SIZE=3D2>concedes that X.509 permits users to be CAs. The =
documents</FONT>
<BR><FONT SIZE=3D2>are clear that part of the (old) motivation =
for</FONT>
<BR><FONT SIZE=3D2>the limitations PEM/PKIX still places on the =
X.509</FONT>
<BR><FONT SIZE=3D2>model were to do with the historical need to </FONT>
<BR><FONT SIZE=3D2>to flow revenues to a patent licensee, =
per-certificate. </FONT>
<BR><FONT SIZE=3D2>Organizational certification supported that goal, =
which</FONT>
<BR><FONT SIZE=3D2>was important to the Internet PKI at the time. Its =
very</FONT>
<BR><FONT SIZE=3D2>hard to deny the legitimacy of either model, note: =
1040 </FONT>
<BR><FONT SIZE=3D2>re-emerged as the wildy successful VeriSign Onsite, =
and </FONT>
<BR><FONT SIZE=3D2>1422's ON model is still in vouge in&nbsp; US/CA =
military </FONT>
<BR><FONT SIZE=3D2>messaging infrastructures.</FONT>
</P>

<P><FONT SIZE=3D2>In terms of consensus, I doubt we can obtain =
any</FONT>
<BR><FONT SIZE=3D2>on this issue in IETF. There are simply two worlds: =
the world</FONT>
<BR><FONT SIZE=3D2>of the philosophy of PKIX, and reality of actual =
needs and </FONT>
<BR><FONT SIZE=3D2>legacy support. Both world views are convincing and =
laudable; convergence is&nbsp; unlikely. Matters of policy and =
application really</FONT></P>

<P><FONT SIZE=3D2>dont need PKIX WG involvement, however. All the =
commodity</FONT>
<BR><FONT SIZE=3D2>software out there is entirely customisable in =
the</FONT>
<BR><FONT SIZE=3D2>field, and vendor-working groups are probably a =
better</FONT>
<BR><FONT SIZE=3D2>forum than PKIX - which properly concentrates on =
leading,</FONT>
<BR><FONT SIZE=3D2>if not fulfilling, the long term infrastructure =
vision.</FONT>
</P>

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

<P><FONT SIZE=3D2>But that is where I see that the problem lies.&nbsp; =
As I mentioned in my </FONT>
<BR><FONT SIZE=3D2>previous emails, we have also had conversations with =
PKIX people that</FONT>
<BR><FONT SIZE=3D2>led </FONT>
<BR><FONT SIZE=3D2>to my belief that there may we irreconcilable =
differences of opinion</FONT>
<BR><FONT SIZE=3D2>about </FONT>
<BR><FONT SIZE=3D2>this approach.&nbsp; There are those who apparently =
believe that the approach</FONT>
<BR><FONT SIZE=3D2>is </FONT>
<BR><FONT SIZE=3D2>fundamentally at odds with X.509 and PKIX world =
views, and should not be</FONT>
</P>

<P><FONT SIZE=3D2>sanctioned.</FONT>
<BR><FONT SIZE=3D2></FONT>&nbsp;
</P>

</BODY>
</HTML>

--Boundary_(ID_M6moA8kprXHxZzeES9hMUQ)--

From: "Marc Jadoul" <[email-masked]>
To: <[email-masked]>
Subject: Timestamping + Cert revocation + revocation question
Date: Tue, 3 Sep 2002 12:55:48 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C25349.39BDC010
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I probably misunderstood something and I have a small question about how =
to 'invalidate' a certificate that has already expired.
Here is a simple scenario:
User A get controle on a certificate certifying User B. It create a =
signature in the name of user B. It then timestamp this signature.
Now User B do not know this. The certificate expire and it is not =
possible to revoke it anymore (right?).
The time-stamped signature is thus valid and I do not know any mean to =
communicate that the certificate was wrong from the begining. Any =
relying party will continue to accept the time-stamped signature, even =
if User B and the CA now know the there was a problem with the =
certificate at the time of the signature.
Does it exist some way to communicate that a certificate was invalid =
from a specific date, even if it is known only after expiration of the =
certificate?

How to invalidate a timestamped signature? In the real world you would =
destroy it but here, it can perfectly be duplicated.

Marc Jadoul

------=_NextPart_000_0015_01C25349.39BDC010
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I probably misunderstood something and =
I have a=20
small question about how to 'invalidate' a certificate that has already=20
expired.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Here is a simple scenario:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>User A get controle on a certificate =
certifying=20
User B. It create a signature in the name of user B. It then timestamp =
this=20
signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Now User&nbsp;B&nbsp;do not&nbsp;know =
this. The=20
certificate expire and it is not possible to revoke it anymore=20
(right?).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The time-stamped signature is thus =
valid and&nbsp;I=20
do not know any mean to communicate that the certificate was wrong from =
the=20
begining. Any relying party will continue to accept the time-stamped =
signature,=20
even if User B and the CA now know the there was a problem with the =
certificate=20
at the time of the signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Does it&nbsp;exist some way to =
communicate that a=20
certificate was invalid from a specific date, even if it is&nbsp;known=20
only&nbsp;after expiration of the certificate?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How to invalidate a timestamped =
signature? In the=20
real world you would destroy it but here, it can perfectly be=20
duplicated.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Marc Jadoul</FONT></DIV></BODY></HTML>

------=_NextPart_000_0015_01C25349.39BDC010--

Date: Mon, 02 Sep 2002 21:43:58 -0500
To: Denis Pinkas <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: Re: Withdrawl of Proxy Cert Profile draft from PKIX
Cc: [email-masked]
Sender: [email-masked]

Denis,

PKIX has already influenced the content of the proxy cert profile 
substantially.  I realized after my last email that "languished" was 
perhaps a poor choice of words.  In fact, the document has progressed 
substantially since its initial submission, based in part upon discussions 
with several PKIX participants.  It would perhaps be better to describe it 
as "languishing" (present tense), as it seems that changes have reached a 
plateau, with no clear path or energy to move it forward in PKIX.  (Though 
maybe this discussion will change that.)

The document is definitely still influenceable, if people are willing to 
expend the effort to attempt to influence it in the near future.  The 
document has evolved substantially during the year and a half it has been 
out there, such that the authors are now pretty happy with it.  But 
frankly, there really is not all that much to this profile. (See 
below.)  If there is acceptance of the fundamental approach of having a 
proxy cert signed by an end-entity cert or another proxy cert, then I think 
reaching consensus on the details should not be hard or take very long 
given the progress we have already made.

But that is where I see that the problem lies.  As I mentioned in my 
previous emails, we have also had conversations with PKIX people that led 
to my belief that there may we irreconcilable differences of opinion about 
this approach.  There are those who apparently believe that the approach is 
fundamentally at odds with X.509 and PKIX world views, and should not be 
sanctioned.

Perhaps this is the straw poll that needs to be taken...

Should PKIX sanction the advancement of a proxy cert draft based on the 
current fundamental approach?  We can argue about the details more later, 
but the fundamental approach at issue is whether it is reasonable to use 
end-entity public key certificates to sign proxy certificates. Possible 
answers are:
   1) No.
   2) Yes, but only as Informational Track.
   3) Yes, as Standards Track.

In order better inform voters, it is perhaps useful for me to summarize the 
approach, and some of the discussions that have occurred.  Note that I have 
purposely omitted names in the following text.  As none of the referenced 
discussions with PKIX people happened in a public forum, I don't want to 
drag them into a public debate against their will.  But of course, I'm 
happy if they jump in and take credit for (and argue for) the suggestions 
and critiques describe below.

A proxy cert is denoted by the presence of the proxyCertInfo extension, 
which must be marked critical.  A proxy cert is signed/issued by either an 
end-entity cert, or by another proxy cert.  The subject of the proxy cert 
is derived from that of its issuer, by taking the issuer DN and appending a 
common name whose value should be unique amongst all proxy certs issued by 
a particular issuer.  The subjectAltName must be empty, and there are rules 
for what is allowed in the proxy cert's key usage and extended key usage 
relative to its issuer.

The proxyCertInfo extension carries three things: a version number, so more 
info can be added to it in a subsequent revision, if desired; a 
pCPathLenConstraint to limit the proxy path length; and a proxyPolicy that 
is just a 2-tuple containing an OID of a policy language, and a policy blob 
expressed in that language.  There are two simple policies defined in the 
draft: one that states that the proxy cert is allowed to impersonate its 
issuer (that is, it inherits all rights that the issuer has), and one that 
states that the proxy cert is independent of its issuer (that is, it 
inherits no rights from its issuer).  Other policy languages can be defined 
that allow for finer grain inheritance of rights from the issuer.

Changes are required to the path validation algorithm, in order to verify 
that the proxy subject is properly derived from the subject of its issuer, 
to verify the key usage and extended key usage are correctly derived from 
the issuer, and to check the pCPathLenConstraint.

That's about it.

The biggest change to the draft came with the -02 version.  Based on 
discussions and suggestions from PKIX members, we changed the way subject 
names were handled in proxies, in order to make them work better with 
attribute certificates.  Prior to that version, we went to some length to 
avoid providing a useful proxy subject, so that a proxy really just 
inherited its name from its issuing end-entity cert.  In other words, it 
was more of a straight impersonation approach -- in essence, we were 
basically just binding temporary keys to an existing end-entity 
subject.  This changed to the approach described above, in which each proxy 
cert is given a unique subject DN, derived from that of its issuer.  This 
allows a proxy cert to be the holder of an attribute cert.

The concern that has been expressed by various PKIX people is that we are 
using end-entity certs to issue proxy certs.  The argument is that we are 
using the end-entity cert like a CA cert, which violates the fundamental 
X.509 and PKIX world view.

At some conceptual level, this is obviously true -- we are creating a key 
pair, creating a unique subject name, and then using the end-entity cert to 
sign a certificate containing the public key, name, and other information 
including the proxyCertInfo.  However:

   1) A proxy certificate is not an end-entity certificate -- a proxy 
cert's reason for existing is quite different from an end-entity cert.  The 
whole point of proxy certs is to allow for relatively short-lived entities, 
which are dynamically created and destroyed, to be given an authenticatable 
identity, optionally accompanied with some delegated rights from the 
issuer.  Issuing certificates using a traditional CA model is not practical 
or efficient for such entities.

   2) Existing code that does not implement proxy cert path validation will 
reject a proxy cert that is presented to it for 2 reasons: (1) the 
BasicConstraints.cA bit of the issuing end-entity is false, and (2) the 
proxyCertInfo extension is marked critical.  So unless existing code is 
horribly mis-implemented (even these most basic checks are not done in its 
path validation), there should be no concern about problems that proxy 
certs can cause to existing implementations.

   3) Code that properly implements proxy cert path validation cannot 
confuse an end-entity cert with a proxy cert.  The proxy cert path 
validation will reject an end-entity cert signed by a proxy cert, or a 
proxy cert that tries to spoof some subject name that is not properly 
derived from that of the issuing end-entity.  So in new code that 
implements proxy cert's, there is clear delineation between the two.

So while at some level an end-entity and proxy cert look a lot alike, they 
are really distinct things, used for distinct purposes, and cannot be 
confused with each other either by an existing implementation that does not 
implement the proxy cert profile, or by a new implementation that properly 
implements the proxy cert profile.

The only alternative approaches that were suggested were:

   A) Have existing CAs issue end-entity certificates with the 
BasicConstraints.cA bit set to true, and name constraints set to restrict 
the subjects of any certs signed by that end-entity.  In other words, 
instead of issuing end-entity certs, issue subordinate CA certs.  An 
advantage to this approach is that it lives within the current X.509/PKIX 
model.  But I believe this approach has a few problems.  First, of the CA 
operators I have talked to, none of them would issue "end-entity" certs 
with the cA bit set to true, as they found that even more counter to the 
X.509/PKIX world view than the introduction of proxy certs.  Second, many 
existing implementations do not implement name constraints, which not only 
means new code would need to be rolled out anyway (just like it does for 
proxies), but that existing code could easily be spoofed by an end-entity 
that signs another end-entity subject.  On this last point, an advantage to 
the current proxy cert profile is that code that has not been explicitly 
coded to accept proxies will reject them due to the existing fundamental 
path validation rules.

   B) Create an CA which automatically issues new end-entity certs on 
demand for the dynamically created entities.  The primary problem with this 
approach is scalability, particularly in a large, widely distributed system 
with lots of dynamically created entities (which is exactly what we are 
building today in various Grid applications using proxy certs).  The 
advantage of the current proxy cert profile is that a proxy can be 
unilaterally created by an existing entity (the holder of an end-entity 
cert or existing proxy cert), with no need for centralization.

   C) Forget X.509, and just use raw keys for what we are trying to 
do.  But the reason we went down the proxy cert path in the first place was 
so that they could drop into existing code base (e.g. SSL/TLS libraries) 
with little modification.  Technical details aside, I also found this 
argument to be curious coming from a PKIX person -- given that PKIX 
specifications as they exist today do not meet our needs, does it make more 
sense to augment the current PKIX specifications as we have done, or is it 
better to just bail on X.509 entirely?

-Steve

At 02:58 AM 8/30/2002, Denis Pinkas wrote:
>Russ,
>
> > Steve:
> >
> > I think that a straw poll is in order.  If the consensus of the group is
> > that this work should proceed, then we simply follow the usual process.  If
> > the consensus of the group is that this work should not proceed, then
> > withdrawal is the appropriate course of action.
> >
> > Would the PKIX WG Chairs please conduct the poll...
>
>Hold on a second.
>
>Is this document going to follow the Standards Track or the Informational
>Track ?
>
>I understood that the document is being progressed in the Grid Forum
>Document and is well advanced. I wonder if the PKIX WG will have the real
>possiblity to influence the content of the document. When a document is
>going on the Standards Track, it has to reflect the consensus of the PKIX
>WG and we all know by experience that it takes much more than a couple of
>months to reach a consensus. I wonder if that time frame is compatible with
>the goals of the people supporting that document.
>
>Now, if the document is going to follow the Informational Track, it can do
>it within or outside the PKIX WG.
>
>Before any strow poll is conducted, it first needs to be clarified whether
>the proposal would be to carry on the work on the Standards Track or the
>Informational Track.
>
>Denis
>
> > Russ
> >
> > At 12:24 AM 8/28/2002 -0500, Steve Tuecke wrote:
> > >Russ,
> > >
> > >So how do we get there from here?
> > >
> > >One fundamental obstacle may be that there are some PKIX participants who
> > >seem to be fundamentally opposed to the approach taken in the proxy cert
> > >profile.  Having had a number of conversations with such people, my belief
> > >is that it is likely an irreconcilable difference.  It seems to be more of
> > >a difference in world-view than in any specific technical detail -- they
> > >believe that using an end-entity certificate to sign proxy certificates is
> > >at fundamental odds with X.509 and PKIX philosophies.
> > >
> > >But even if we are able to resolve this difference (e.g. either through
> > >finding an approach that we all agree on, or by agreeing to disagree but
> > >moving forward anyway), I guess its not clear to me how we overcome the
> > >energy barrier to advance it to an RFC.  There seems to be a general
> > >apathy within PKIX participants toward advancing this draft.  (And please
> > >realize that I am not faulting anybody by making this statement.  We all
> > >have our own agendas within PKIX, and it may just be that mine is too far
> > >off the radar for most.)
> > >
> > >I'm completely comfortable with PKIX making a consensus decision that the
> > >Proxy Cert Profile should not be considered further in PKIX.  I'm also
> > >happy to push forward with it if there is support for doing so.  But given
> > >that it is currently languishing in PKIX, and that I don't see an obvious
> > >path toward reaching consensus in PKIX on this profile, I felt the most
> > >reasonable route was to suggest the withdrawal of the draft from PKIX.
> > >
> > >-Steve
> > >
> > >At 02:57 PM 8/27/2002, Housley, Russ wrote:
> > >>Steve:
> > >>
> > >>I would like to see certificate handling libraries support the delegation
> > >>environment, and the people that write such libraries are currently
> > >>paying attention to the PKIX WG.  So, that is my preferred route.
> > >>
> > >>Russ
> > >>
> > >>At 02:05 PM 8/27/2002 -0500, Steve Tuecke wrote:
> > >>>Russ,
> > >>>
> > >>>There are, of course, two avenues to RFC -- one through a working group,
> > >>>and the other as an individual submission.  I am curious what you think
> > >>>of each of these avenues, and more generally why you would prefer to see
> > >>>it published as an RFC.  For broad acceptability of the profile, the
> > >>>best route is obviously PKIX.  But if that doesn't happen, is there any
> > >>>value to it being an individually submitted informational RFC, in
> > >>>addition to a GGF (RFC-like) GFD?  (The GGF document process is pretty
> > >>>similar to IETF.)
> > >>>
> > >>>-Steve
> > >>>
> > >>>At 01:01 PM 8/27/2002, Housley, Russ wrote:
> > >>>>Steve:
> > >>>>
> > >>>>I understand the need for you to make progress.  And, I will support
> > >>>>any pragmatic decision that you make.  However, I would prefer to see
> > >>>>this profile published as an RFC.
> > >>>>
> > >>>>Russ
> > >>>>
> > >>>>At 11:47 AM 8/27/2002 -0500, Steve Tuecke wrote:
> > >>>>
> > >>>>>All,
> > >>>>>
> > >>>>>In February 2001 we wrote a first draft of "Internet X.509 Public Key
> > >>>>>Infrastructure Proxy Certificate Profile" (draft-ietf-pkix-proxy-02)
> > >>>>>and introduced it into the Global Grid Forum (GGF, www.gridforum.org).
> > >>>>>Shortly after that, because it seemed to relate to the work in PKIX,
> > >>>>>we also introduced it into the PKIX working group.  Tim and Steve
> > >>>>>accepted this draft into PKIX and gave me time at several IETFs to
> > >>>>>present progress on this draft (for which we are most grateful!),
> > >>>>>which led to many useful discussions with IETF folks.  Over the past
> > >>>>>year and a half, we have continued to refine the draft as a result of
> > >>>>>this input and our own continuing work in this area.
> > >>>>>
> > >>>>>We are now trying to reach closure on this draft, so that various
> > >>>>>groups, including our Globus Project, can implement and deploy to a
> > >>>>>non-moving target.  There is strong support in the GGF Grid Security
> > >>>>>Infrastructure (GSI) working group to finalize the draft, and push it
> > >>>>>on to become a Grid Forum Document (GFD), which is GGF's equivalent of
> > >>>>>an RFC. However, within the PKIX community I think its fair to say
> > >>>>>that it has received little attention, and the reactions that have
> > >>>>>been expressed have been mixed -- everywhere from strong disagreement
> > >>>>>to strong support of the approach.
> > >>>>>
> > >>>>>We have a new, significantly cleaned up draft available at
> > >>>>>http://www.gridforum.org/2_SEC/GSI.htm, though we have NOT yet
> > >>>>>submitted it to IETF, pending the outcome of this discussion.
> > >>>>>
> > >>>>>Our current intention is to withdraw this document from PKIX
> > >>>>>consideration, and finish it up within GGF.  (The previous
> > >>>>>draft-ietf-pkix-proxy-02 expires this month.)  However, if there is a
> > >>>>>public ground swell to complete it within PKIX, we are happy to 
> reconsider.
> > >>>>>
> > >>>>>Meanwhile, this draft is currently in last-call in the GGF GSI working
> > >>>>>group, prior to submitting it for consideration to become a GFD.  We
> > >>>>>would be happy to receive and incorporate feedback to the latest GGF
> > >>>>>draft (see above URL), prior to the final submission (hopefully within
> > >>>>>in a couple weeks).
> > >>>>>
> > >>>>>Thanks,
> > >>>>>-Steve
> > >>>>>------------------------------------------------------------------- 
> -----
> > >>>>>Steve Tuecke           MCS, Bldg 221, Office B-159  work: (630) 
> 252-8711
> > >>>>>[email-masked]     Argonne National Laboratory  cell: (630) 
> 842-6917
> > >>>>>http://www.mcs.anl.gov/~tuecke Argonne, IL 60439   fax: (630) 252-5986

Subject: Re: draft-ietf-pkix-warranty-ext-01
To: Denis Pinkas <[email-masked]>
Cc: Anders Rundgren <[email-masked]>, [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 2 Sep 2002 13:38:54 -0600
Sender: [email-masked]

In addtion to insurance premiums proportional to risk
http://www.garlic.com/~lynn/aadsm12.htm#20" draft-ietf-pkix-warranty-ext-01
There are actually a couple of issues:

a) security/insurance proportional to risk. in the online world ... the
RP/merchant may get a surcharge per transaction that pays for insurance on
per transaction basis. they may also have one-time disaster insurance ...
that is sort of independent of the number of transactions ... but
represents some total value that is at risk

b)  the entity at risk pays for the insurance. typically the business
arrangement is between the CA and the entity being certified. if it is a
merchant certificate then the CA can charge a little bit more for the
insurance to cover damages where the merchant might get sued. if it is a
consumer certificate .... the consumer is being charge but typically the
merchant is still the one at risk; not the consumer (this is because there
are special provisions favoring consumers in retail transactions .... this
wouldn't apply between two equal parties in commercial transactions).
Ignoring for a moment the issue of whether (offline paradigm) certificates
are needed in the online world, there is a separate issue that the entity
primarily at risk is not party to the CA/consumer business transaction.
There is nominally no direct business relationship between the CA & the
merchant in the case of consumer certificates .... so it is difficult for a
merchant to establish liability (possibility other civil legal issues)
against the CA.  Difficult for a merchant to sue a consumer because of CA
liability to the consumer.

CAs either have to

1) convince consumers that certificates are good for something that
consumers have at risk (say identity theft) for which the CA can justify
charging the consumer extra to cover the cost of doing business as well as
ancillary things like  insurance  ... or

2) CAs have to revamp the business model so that there is a contractual
relationship between the CA and the RP ... and be able to charge on the
basis of that   ... or

3) get gov. to pass mandated certificate requirements.

now ... if

1) if consumers (or any party) aren't at risk ... it is hard to get them to
(directly) pay anything

2) if a contractual relationship between CAs and RPs can be fabricated ....
then you are likely to have relying-party-only certificates .... the RPs
pay either directly or indirectly (so that there is a contractual
relationship with the CA on which money flow can be based) ...  the RPs
will pass on the cost for relying-party-only certificates to the consumer
.... but it is a business solution to match the money flow with who is at
risk and the contractual relationships. The downside here is that it is
trivially possible to show that relying-party-only certificates in an
online, transaction world are redundant and superfluous. This establishes
some basis for civil litigation.

3) if you can get a gov. to pass bills mandating something ... then you can
eliminate any civil liability issues with the contractual relationships and
money flow not matching parties at risk.

I believe there has been lots of past discussions regarding the difficulty
in the commercial world of establish money flow & risk with the RP in a
standard CADS paradigm (the RP being at risk but original CADS business
model had no contractual relationship between the CA and the RP). I believe
the FED GSA PKI stuff has tried to resolve this by contorting the business
model that the contractual relationship is between GSA and the CAs .... and
that the CAs are providing (relying-party) certificates to end-users. CAs
may levy a surcharge on the end-users for the certificate issuing ... but
the business relationship is not between the CA and the end-user .... it is
between the CA and GSA (the relying party). Note that since the business
relationship is between the CA and the GSA, the contract(s) call out the
warranties and liabilities.  In this case, certificates would be considered
a service provided and independent of the contract documents and the
specifications of T&Cs, warranties, liabilities and things like insurance.

The next step would be to get some kind of legislative bill passed that
mandates such certificates .... even when it can be proven that they are
redundant and superfluous in an online world.

random refs on relying party certificates:
http://www.garlic.com/~lynn/subtopic.html#rpo

[email-masked] wrote:

Alice,

I concur with many of the arguments raised by Anders. It is very scarce,
but
this time it happened, thanks to your draft. :-)

I believe that sufficient arguments have been raised against the
progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely,
only
errors made by the CA personal or attributed to the CA during the
management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.

Regards,

Denis

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 02 Sep 2002 11:26:19 -0400
Subject: Re: rfc822name Name Constraints question
Sender: [email-masked]

Anne:

The email address name constraint contains the right-hand part.  So, any 
email address that exactly matches the right-hand part in the name 
constraint is valid.

>RFC3280 describes how name constraints for "Internet mail
>addresses" may be specified, but is unclear on a few points:
>
>1. If the NameConstraint is "[email-masked]", does that include
>    "[email-masked]"?

Yes.  The email address "[email-masked]" does satisfy the "[email-masked]" 
constraint.

>2. Can "@xyz.com" be used to match all mail addresses at
>    "xyz.com" but not addresses at "abc.xyz.com?

Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes (or 
.forward entries) on the host xyz.com.

>3. The paragraph says the constraint "xyz.com" is satisfied by
>    "any mail address at the host "xyz.com", and ".xyz.com" is
>    satisfied by an address within the domain xyz.com, but not
>    xyz.com itself.  How then do I specify all addresses in the
>    domain xyz.com AND xyz.com itself?

The constraint "xyz.com" permits "[email-masked]" and "[email-masked]"

Russ

Date: Mon, 02 Sep 2002 12:50:08 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: Anders Rundgren <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-warranty-ext-01
Sender: [email-masked]

Alice,

I concur with many of the arguments raised by Anders. It is very scarce, but
this time it happened, thanks to your draft. :-) 

I believe that sufficient arguments have been raised against the progression
of this draft, as it stands, which does not even explicitly states, for a
naive reader, what the warranty is about.

The warranty is concerned with the liability of the CA, more precisely, only 
errors made by the CA personal or attributed to the CA during the management
of the certificate, e.g. at the time of registration of the subject, when
issuing the certificate, when handling revocation requests or when making
available revocation status information.

Regards,

Denis

> Alice,
> 
> >Lynn observed that the world of financial risk management is moving past
> >per-transaction model.  The proposed extension offers an aggregate model.
> >Also Lynn wrote: "and any migration to an offline paradigm with
> >> both support for per transaction as well as aggregation risk/limits
> >> obsoletes the requirement for the certificate."
> >That's true; that's why the extension is useful.  If total risk, i.e.,
> >aggregated transactions, is the primary worry of the insurance industry then
> >the aggregate model would be appropriate.
> 
> This sounds pretty dangerous as it gives no value to an RP which may be just
> one of several thousands of RPs which just received a purchase order
> from a company that is on the edge of filing for bankruptcy.
> 
> If it is of no value to RPs, the only purpose left for the warranty-extension
> is for a CA to insert its liability limit in a machine-readable
> format.  Is this really interesting as any liability above zero is likely
> to be accompanied by a non-machine-interpretable agreement?
> 
> Is the intent, that the moment a transaction is received that exceeds
> the liability limit, an alert is to be sent to the legal department?
> Depending on the liability agreement this may be too late
> as lower-amount transactions may be equally uncovered.
> 
> Actually it would IMO better be a part of the CA-certificate to
> declare what it stands for in terms of liability.
> 
> Regarding warranted purchase orders, I have serious problems
> understanding what a CA-issued warranty could possibly cover except
> for a liability for having certified the wrong entity which is now making
> fake orders.  But IMHO such a warranty is equally applicable to
> authentications, as incorrect such are even worse as you cannot
> "rollback" authentication events.
> 
> For pure financial transactions, there are already solutions in place
> since ages ago, like bank-warranties, remburses and pre-paid orders.
> 
> cheers,
> Anders

Date: Sun, 01 Sep 2002 12:57:08 -0700
To: [email-masked], [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Wildcard certificates
Cc: EKR <[email-masked]>
Sender: [email-masked]

Eric said:
> As Steve Kent points out, dNSNames cannot contain *s.
> However, since CN is the standard place to put the DNS name
> (much to everyone's unhappiness) they often contain *s. Don't
> know if anyone actually uses dNSName for this. 

Most LDAP implementations do this... per RFC 2830, Section 3.6.

Kurt

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-pkix-warranty-ext-01
Date: Sun, 1 Sep 2002 17:48:51 +0200
Sender: [email-masked]

Alice,

>Lynn observed that the world of financial risk management is moving past
>per-transaction model.  The proposed extension offers an aggregate model.
>Also Lynn wrote: "and any migration to an offline paradigm with
>> both support for per transaction as well as aggregation risk/limits
>> obsoletes the requirement for the certificate."
>That's true; that's why the extension is useful.  If total risk, i.e.,
>aggregated transactions, is the primary worry of the insurance industry then
>the aggregate model would be appropriate.

This sounds pretty dangerous as it gives no value to an RP which may be just
one of several thousands of RPs which just received a purchase order
from a company that is on the edge of filing for bankruptcy.

If it is of no value to RPs, the only purpose left for the warranty-extension
is for a CA to insert its liability limit in a machine-readable
format.  Is this really interesting as any liability above zero is likely
to be accompanied by a non-machine-interpretable agreement?

Is the intent, that the moment a transaction is received that exceeds
the liability limit, an alert is to be sent to the legal department?
Depending on the liability agreement this may be too late
as lower-amount transactions may be equally uncovered.

Actually it would IMO better be a part of the CA-certificate to
declare what it stands for in terms of liability.

Regarding warranted purchase orders, I have serious problems
understanding what a CA-issued warranty could possibly cover except
for a liability for having certified the wrong entity which is now making
fake orders.  But IMHO such a warranty is equally applicable to
authentications, as incorrect such are even worse as you cannot
"rollback" authentication events.

For pure financial transactions, there are already solutions in place
since ages ago, like bank-warranties, remburses and pre-paid orders.

cheers,
Anders

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-pkix-warranty-ext-01
Date: Sun, 1 Sep 2002 07:49:11 -0400
Importance: Normal
Sender: [email-masked]

Denis, Lynn, and others,

Denis, you wrote: "While, as you say, the basic intent of
the proposed extension is building confidence in e-business, in reality it
would build a FALSE confidence in e-busines, then doing more harm that
benefits. I disagree that processing only the amount field allows to build
confidence."

This seems to be the crux of our disagreement. I do believe that the
extension will add confidence in e-business. Its presence alone provides
some modicum of assurance that the matter of warranty for transactions has
been addressed. This in and of itself gives any RP confidence in the
transaction.

You wrote: "Incorporating static warranty conditions in a
certificate is not appropriate or would be appropriate only if there would
be some kind of on-line check done afterwards. The information would only be
used, to know whether or not it makes sense to do perform an on-line check
or not (and where). However, this is not the meaning of the proposed
extension."

You're right that this is not the purpose of the extension. Checking
afterwards is not necessary to fulfill the purpose of the extension which is
to show that some kind of warranty does exist for the transaction and/or the
certificate in use.  That in itself is sufficient.  It can also be easily
processed by the asn.1 syntax.

Lynn observed that the world of financial risk management is moving past
per-transaction model.  The proposed extension offers an aggregate model.
Also Lynn wrote: "and any migration to an offline paradigm with
> both support for per transaction as well as aggregation risk/limits
> obsoletes the requirement for the certificate."
That's true; that's why the extension is useful.  If total risk, i.e.,
aggregated transactions, is the primary worry of the insurance industry then
the aggregate model would be appropriate.

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