Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt

From: Ulf Möller <[email-masked]>
Date: Thu, 24 Nov 2005 17:55:41 +0100

Hello,

We have implemented a client that uses PKIXREP to locate an LDAP service for
an e-mail address. However I have not found anyone who announces their
directory in DNS according to this specification.

If there is anyone who does, I'd appreciate a message. It would be nice if
we could perform some interoperability tests.

The draft doesn't specify the LDAP search base. According to the expired
draft-ietf-ldapext-locate-08, you would use a DC style distinguished name.
Am I right in assuming that the same holds for PKIXREP?

Ulf Möller

=======================================
Secardeo GmbH
Betastrasse 9a
85774 Unterfoehring
GERMANY

Office      +49 (0)89 -18 93 58 95
Fax         +49 (0)89 -18 93 58 99
E-mail      [email-masked]
WWW         http://www.secardeo.com
=======================================

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Nov 2005 12:58:45 -0500

This was just published last week as an Experimental RFC.  I would 
like to know if people find it useful.

Russ

>Am I right in assuming that the same holds for PKIXREP?

Date: Fri, 25 Nov 2005 12:58:45 -0500
To: Ulf Möller <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt
Sender: [email-masked]

This was just published last week as an Experimental RFC.  I would 
like to know if people find it useful.

Russ

At 11:55 AM 11/24/2005, Ulf Möller wrote:

>===================>Secardeo GmbH
>Betastrasse 9a
>85774 Unterfoehring
>GERMANY
>
>===================>

From: =?iso-8859-1?Q?Ulf_Möller?= <[email-masked]>
To: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-04.txt
Date: Thu, 24 Nov 2005 17:55:41 +0100
Organization: Secardeo GmbH
Sender: [email-masked]

Hello,

Ulf Möller

===================Secardeo GmbH
Betastrasse 9a
85774 Unterfoehring
GERMANY

=================== 

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, pkix mailing list <[email-masked]>, pkix chair <[email-masked]>, pkix chair <[email-masked]>
Subject: Document Action: 'Internet X.509 Public Key Infrastructure  Repository Locator Service' to Experimental RFC 
Date: Tue, 22 Nov 2005 13:20:44 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Repository Locator Service '
   <draft-ietf-pkix-pkixrep-04.txt> as an Experimental RFC

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

The IESG contact persons are Russ Housley and Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-04.txt

Technical Summary

  This document defines a PKI repository locator service.  The service
  makes use of DNS SRV records defined in accordance with RFC 2782.  The
  service enables certificate using systems to locate PKI repositories
  based on a domain name, identify the protocols that can be used to
  access the repository, and obtain addresses for the servers that host
  the repository service.

Working Group Summary

  The PKIX Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.

Date: Fri, 18 Nov 2005 15:56:53 -0500
To: Blake Ramsdell <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: "Gregory S. Chudov" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 11:14 AM -0800 11/18/05, Blake Ramsdell wrote:
>On Nov 18, 2005, at 11:09 AM, Stephen Kent wrote:
>>Sorry. What I meant to say in my previous message was that I 
>>requested that a fresh (vs. expired) copy of the I-D in question be 
>>posted, so that we could initiate last call in PKIX.  Please you 
>>provide a URL for that copy.
>
>Just to make sure we're talking about the same document -- I'm 
>talking about draft-ietf-pkix-gost-cppk-03

Yes, that I-D is OK.  I will initiate WG last call on it.

Date: Fri, 18 Nov 2005 15:58:41 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Last Call
Sender: [email-masked]

I am initiating last call on:  draft-ietf-pkix-gost-cppk-03.txt, an 
I-D targeted as INFORMATIONAL.

Please provides comments to the list between now and the end of the month.

Steve

Cc: "Gregory S. Chudov" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
From: Blake Ramsdell <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Fri, 18 Nov 2005 11:14:54 -0800
To: Stephen Kent <[email-masked]>
X-ok-sendmail.com: Yes
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

On Nov 18, 2005, at 11:09 AM, Stephen Kent wrote:
> Sorry. What I meant to say in my previous message was that I  
> requested that a fresh (vs. expired) copy of the I-D in question be  
> posted, so that we could initiate last call in PKIX.  Please you  
> provide a URL for that copy.

Just to make sure we're talking about the same document -- I'm  
talking about draft-ietf-pkix-gost-cppk-03

https://datatracker.ietf.org/public/idindex.cgi? 
command=id_detail&id620

http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt

Which points to a draft submitted on 9/9 and expires March, 2006. The  
draft announcement to the PKIX list is here:

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

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Date: Fri, 18 Nov 2005 14:09:50 -0500
To: "Gregory S. Chudov" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: <[email-masked]>, "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>Greetings.
>
>We are ready for last call on gost-cppk too.
>
Sorry. What I meant to say in my previous message was that I 
requested that a fresh (vs. expired) copy of the I-D in question be 
posted, so that we could initiate last call in PKIX.  Please you 
provide a URL for that copy.

Thanks,

Steve

Date: Fri, 18 Nov 2005 11:48:25 -0500
To: "Gregory S. Chudov" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Cc: <[email-masked]>, <[email-masked]>, "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 3:45 PM +0300 11/18/05, Gregory S. Chudov wrote:
>Greetings.
>
>We are ready for last call on gost-cppk too.
>

I sent a message

Date: Fri, 18 Nov 2005 17:24:37 +0100
From: David Lefranc <[email-masked]>
To: [email-masked]
Subject: Certificates and Blind Signatures
Sender: [email-masked]

Hi,

I would like to use a blind RSA signature algorithm, and I am currently 
analyzing the best way to use X509 certificates : I need to precise that 
the public key will be used with such an algorithm.

The easiest solution would be to create a new algorithmIdentifier 
identifying the Blind RSA signature algorithm so that I could use it in 
the field subjectPublicKeyInfo.
However, since blind RSA signature and classical signature algorithms 
are quite similar, I think a better solution would be the following :

1. Keep the algorithmIdentifier for the classical RSA signature 
algorithm in the field subjectPublicKeyInfo.
2. Do not use the Key Usage extension.
3. Use the Extended Key Usage extension, set it as "non critical", and 
create a new KeyPurposeId for "blind signature", (and also eventually 
precise DigitalSignature and NonRepudiation).

With this second solution, the system for blind RSA signatures that I 
develop SHOULD require such certificates, and the certificates could 
also be used in a classical way outside my system to perform classical  
RSA signatures.

Does it seem reasonable?

David

From: "Gregory S. Chudov" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt
Date: Fri, 18 Nov 2005 15:45:26 +0300
Sender: [email-masked]

Greetings.

We are ready for last call on gost-cppk too.

----- Original Message ----- 
From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>; "Sean Turner" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 18, 2005 2:04 AM
Subject: Re: WG LAST CALL: draft-ietf-smime-gost-05.txt

> 
> On Nov 17, 2005, at 2:13 PM, Turner, Sean P. wrote:
>> PS there is a companion GOST documents in PKIX
>> (http://ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-03.txt)  
>> and in
>> RFC editor's queue
>> (ftp://ftp.isi.edu/internet-drafts/draft-popov-cryptopro- 
>> cpalgs-04.txt).
> 
> Are we going to run into another CMC / symkeydist situation here?  
> That is, is gost-cppk going to get stuck for any reason in PKIX? I  
> note that the last draft revision is 9/9/05 and I did not see  
> anything to indicate that there is active discussion about this draft  
> on the PKIX list.
> 
> Just firing a warning shot that cppk is a normative reference that  
> will need to progress through PKIX before gost-05 can complete.  
> Authors -- can you give a quick status update about this?
> 
> cpalgs looks pretty frictionless -- no missing normative references,  
> and in the editor's queue.
> 
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
> 
>

Date: Mon, 14 Nov 2005 19:05:52 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College
To: pkix <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090706050508090406040208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David A. Cooper wrote:
> Massimiliano,
> 
> At the moment, there is no way to accomplish what you are trying to do 
> in general.

:-(

> I should begin by pointing out that the text that you quoted from RFC 
> 3280 has been changed in 3280bis so that it no longer mentions CRLs:
> 
>   The id-ad-caRepository OID is used when the subject is a CA, and
>   publishes certificates it issues in a repository.  The accessLocation
>   field is defined as a GeneralName, which can take several forms.

So in 3280bis this will not provide a generalized pointer to certs AND
CRLs but only to certs repositories, right ?

> If a CA issues full CRLs then what you are trying to accomplish may be 
> possible.  If the CA makes its certificates and CRLs available in a 
[...]
> certificates could not be updated to add these new segments.

Is there any chance we can define a `SubjectRevocationAccess' extension
that will point to revocation informations provided by the Subject of the
certificate it appears in ? Is a bad idea ? Could it be added to the
3280bis ?

Thanks to all for any comment/support!

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                   [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

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

--------------ms090706050508090406040208--

Date: Mon, 14 Nov 2005 18:57:55 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College
To: pkix <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000800070606020107080508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> SIA could be used to provide the pointer that you seek, but I do not 
> think that anyone uses it that way.  In fact, I suspect that a document 

That was my original point, but I do agree no one is actually using it
in this way...

> would need to be written to tell people how to do it in an interoperable 
> way.  If you want to pursue that, you would need to write an 
> internet-draft and convince the PKIX WG that it wants to adopt it as a 
> work item.

Now the next step is to understand if this could be useful in real environments
or not... well, obviously I think so, but I would like to have other opinions
about this.

Thanks for the answer!

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

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

--------------ms000800070606020107080508--

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: RFC-3280 [Subject Information Access]
Date: Mon, 14 Nov 2005 17:20:59 -0500
Importance: Normal
Sender: [email-masked]

There are several issues like this for CA -- OCSP Responder communication
that are not covered by 2560 and could stand some guidance or
standardization in a new I-D or revision of 2560.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Monday, November 14, 2005 2:16 PM
To: Massimiliano Pala
Cc: pkix
Subject: Re: RFC-3280 [Subject Information Access]

SIA could be used to provide the pointer that you seek, but I do not 
think that anyone uses it that way.  In fact, I suspect that a 
document would need to be written to tell people how to do it in an 
interoperable way.  If you want to pursue that, you would need to 
write an internet-draft and convince the PKIX WG that it wants to 
adopt it as a work item.

Russ

At 01:51 PM 11/14/2005, Massimiliano Pala wrote:
>Hi Russ,
>
>thank for the answer, but probably due to my bad english I was not 
>really clear... my situation is this:
>
>- I have an OCSP server and I want it to be able to "auto" configure the
>   downloading of CRLs, provided some pointer is given in the CA cert for
>   its own certs, this is:
>
>         * I have only CA2 cert
>
>         * I want to access CRLs issued by CA2
>
>         * No other info is given to the server besides the CA2 cert
>
>The question is if there are extensions/methods to do that without 
>having to access at least one certificate issued by CA2 (where the CDP 
>will provide the pointer I need).
>
>My guess is that SubjectInformationAccess could be used, but its 
>definition is quite broad and I was looking for something more 
>specific... easy for the developers...
>
>Russ Housley wrote:
>>Massimiliano:
>>
>>>Now I am confused... sorry I did not get your question. Let me 
>>>explain by using an example:
>>>
>>>         rootCA -> CA1 -> CA2 -> UserCert
>[...]
>>If each of these certificates contains a CRL DP, then you do not
>>need any further information.
>>CA2 -> UserCert:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by CA2 that will include an entry for 
>>UserCert if it is revoked.
>>CA1 -> CA2:  The CRL DP in this certificate will provide a pointer 
>>to the CRL issued by CA1 that will include an entry for CA2 if it is
revoked.
>>rootCA -> CA1:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by rootCA that will include an entry for 
>>CA1 if it is revoked.
>
>--
>
>Best Regards,
>
>         Massimiliano Pala
>
>--o------------------------------------------------------------------------
>Massimiliano Pala [OpenCA Project Manager]            [email-masked]
>                                                  
>[email-masked]
>
>Dartmouth Computer Science Dept                     Tel.: +1 (603) 397-3883
>PKI/Trust
>--o--------------------------------------------------------------------
>----

Date: Mon, 14 Nov 2005 15:34:08 -0500
From: "David A. Cooper" <[email-masked]>
To: Massimiliano Pala <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Sender: [email-masked]

Massimiliano,

At the moment, there is no way to accomplish what you are trying to do 
in general.

I should begin by pointing out that the text that you quoted from RFC 
3280 has been changed in 3280bis so that it no longer mentions CRLs:

   The id-ad-caRepository OID is used when the subject is a CA, and
   publishes certificates it issues in a repository.  The accessLocation
   field is defined as a GeneralName, which can take several forms.

If a CA issues full CRLs then what you are trying to accomplish may be 
possible.  If the CA makes its certificates and CRLs available in a 
directory and you know the directory and the name of the CA, then you 
should be able to obtain the CA's CRL if it issues a full CRL (see RFC 
2587).  If a CA issues full CRLs, but you cannot use this method to find 
the CRL, then you will need to look at the cRLDistributionPoints 
extension in one of the certificates issued by the CA to determine where 
to obtain the CRL.

The biggest problem will be if the CA only issues segmented CRLs.  In 
this case looking at a single certificate issued by the CA will not be 
sufficient, since different certificates will point to different CRL 
segments.  For such a CA it would also not be possible to use some new 
accessMethod in the subjectInfoAccess extension since the CA may create 
new CRL segments as it issues certificates and the SIA extensions of 
certificates could not be updated to add these new segments.

Dave

Massimiliano Pala wrote:

> Hi Russ,
>
> thank for the answer, but probably due to my bad english I was not really
> clear... my situation is this:
>
> - I have an OCSP server and I want it to be able to "auto" configure the
>   downloading of CRLs, provided some pointer is given in the CA cert for
>   its own certs, this is:
>
>     * I have only CA2 cert
>
>     * I want to access CRLs issued by CA2
>
>     * No other info is given to the server besides the CA2 cert
>
> The question is if there are extensions/methods to do that without having
> to access at least one certificate issued by CA2 (where the CDP will 
> provide
> the pointer I need).
>
> My guess is that SubjectInformationAccess could be used, but its 
> definition
> is quite broad and I was looking for something more specific... easy 
> for the
> developers...

Massimiliano Pala wrote:

> Hi all,
>
> Is there a way for a CA to specify its own (not its issuer's) CRL
> distribution point in its certificate ?
>
> I am asking this because the only way I found so far is by using
> the Subject Information Access with id-ad-caRepository as accessMethod.
> The problem is that its definition is too broad, therefore the URI I
> can put in there could address a CRL or Certs repository or other
> services.
>
> From the RFC-3280 (pp 47):
>
> << The id-ad-caRepository OID is used when the subject is a CA, and
>    publishes its certificates and CRLs (if issued) in a repository.  The
>    accessLocation field is defined as a GeneralName, which can take
>    several forms. >>
>
> While the accessLocation is quite simple to deal with, we should have
> different accessMethod ids at least for CRLs and Certificates 
> repositories.
>
> In other words, is there a method to access the CRLs of a CA from the 
> CA's
> certificate only ?
>
> Am I missing something here ?
>

Date: Mon, 14 Nov 2005 14:16:24 -0500
To: Massimiliano Pala <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Cc: pkix <[email-masked]>
Sender: [email-masked]

SIA could be used to provide the pointer that you seek, but I do not 
think that anyone uses it that way.  In fact, I suspect that a 
document would need to be written to tell people how to do it in an 
interoperable way.  If you want to pursue that, you would need to 
write an internet-draft and convince the PKIX WG that it wants to 
adopt it as a work item.

Russ

At 01:51 PM 11/14/2005, Massimiliano Pala wrote:
>Hi Russ,
>
>thank for the answer, but probably due to my bad english I was not really
>clear... my situation is this:
>
>- I have an OCSP server and I want it to be able to "auto" configure the
>   downloading of CRLs, provided some pointer is given in the CA cert for
>   its own certs, this is:
>
>         * I have only CA2 cert
>
>         * I want to access CRLs issued by CA2
>
>         * No other info is given to the server besides the CA2 cert
>
>The question is if there are extensions/methods to do that without having
>to access at least one certificate issued by CA2 (where the CDP will provide
>the pointer I need).
>
>My guess is that SubjectInformationAccess could be used, but its definition
>is quite broad and I was looking for something more specific... easy for the
>developers...
>
>Russ Housley wrote:
>>Massimiliano:
>>
>>>Now I am confused... sorry I did not get your question. Let me explain by
>>>using an example:
>>>
>>>         rootCA -> CA1 -> CA2 -> UserCert
>[...]
>>If each of these certificates contains a CRL DP, then you do not 
>>need any further information.
>>CA2 -> UserCert:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by CA2 that will include an entry for 
>>UserCert if it is revoked.
>>CA1 -> CA2:  The CRL DP in this certificate will provide a pointer 
>>to the CRL issued by CA1 that will include an entry for CA2 if it is revoked.
>>rootCA -> CA1:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by rootCA that will include an entry for 
>>CA1 if it is revoked.
>
>--
>
>Best Regards,
>
>         Massimiliano Pala
>
>--o------------------------------------------------------------------------
>Massimiliano Pala [OpenCA Project Manager]            [email-masked]
>                                                  [email-masked]
>
>Dartmouth Computer Science Dept                     Tel.: +1 (603) 397-3883
>PKI/Trust
>--o------------------------------------------------------------------------

Date: Mon, 14 Nov 2005 13:51:42 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000607020907050505030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Russ,

thank for the answer, but probably due to my bad english I was not really
clear... my situation is this:

- I have an OCSP server and I want it to be able to "auto" configure the
   downloading of CRLs, provided some pointer is given in the CA cert for
   its own certs, this is:

	* I have only CA2 cert

	* I want to access CRLs issued by CA2

	* No other info is given to the server besides the CA2 cert

The question is if there are extensions/methods to do that without having
to access at least one certificate issued by CA2 (where the CDP will provide
the pointer I need).

My guess is that SubjectInformationAccess could be used, but its definition
is quite broad and I was looking for something more specific... easy for the
developers...

Russ Housley wrote:
> 
> Massimiliano:
> 
>> Now I am confused... sorry I did not get your question. Let me explain by
>> using an example:
>>
>>         rootCA -> CA1 -> CA2 -> UserCert
[...]
> If each of these certificates contains a CRL DP, then you do not need 
> any further information.
> 
> CA2 -> UserCert:  The CRL DP in this certificate will provide a pointer 
> to the CRL issued by CA2 that will include an entry for UserCert if it 
> is revoked.
> 
> CA1 -> CA2:  The CRL DP in this certificate will provide a pointer to 
> the CRL issued by CA1 that will include an entry for CA2 if it is revoked.
> 
> rootCA -> CA1:  The CRL DP in this certificate will provide a pointer to 
> the CRL issued by rootCA that will include an entry for CA1 if it is 
> revoked.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept                     Tel.: +1 (603) 397-3883
PKI/Trust
--o------------------------------------------------------------------------

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

--------------ms000607020907050505030602--

Date: Sun, 13 Nov 2005 19:05:25 -0500
To: Massimiliano Pala <[email-masked]>, pkix <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Sender: [email-masked]

Massimiliano:

>Now I am confused... sorry I did not get your question. Let me explain by
>using an example:
>
>         rootCA -> CA1 -> CA2 -> UserCert

Since you do not say anything about indirect CRLs, I'll assume that 
it has nothing to do with your question.  My response ignores indirect CRLs.

If each of these certificates contains a CRL DP, then you do not need 
any further information.

CA2 -> UserCert:  The CRL DP in this certificate will provide a 
pointer to the CRL issued by CA2 that will include an entry for 
UserCert if it is revoked.

CA1 -> CA2:  The CRL DP in this certificate will provide a pointer to 
the CRL issued by CA1 that will include an entry for CA2 if it is revoked.

rootCA -> CA1:  The CRL DP in this certificate will provide a pointer 
to the CRL issued by rootCA that will include an entry for CA1 if it 
is revoked.

Russ

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC-3280 [Subject Information Access]
Date: Sat, 12 Nov 2005 20:40:29 -0500
Importance: Normal
Sender: [email-masked]

Tom,

See responses in-line under [Santosh:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Saturday, November 12, 2005 4:05 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: RFC-3280 [Subject Information Access]

        Santosh, Massimiliano:

        I'm confused by the way in which one would enable "a CA to specify 
its own (not its issuer's) CRL distribution point in its certificate". 

[Santosh: A CRL DP in a certificate will point to location(s) from which
revocation information for that certificate can be obtained.]

Does this mean the distribution point covering the CA (which should 
already be in the certificate issued to this CA) or a distribution point 
containing a CRL created by the CA (which gets put into the CRL DP of a 
certificate it creates)?

[Santosh: Again, a CRL DP in certificate points to CRL that covers the
status of the certificate.]

  And does it go into a certificate issued to the 
CA by another CA (in which case it can't be specified in this way), a 
certificate issued by the CA to somebody else (the purpose for which CRL 
DP's were designed, unless it's a CRL covering the CA), or a rollover 
self-issued certificate?

[Santosh: I am not sure what you are saying above.  But, a CRL DP in a
certificate will point to location(s) from which revocation information for
that certificate can be obtained.]

A relying party certainly needs to have revocation information for 
an intermediate CA, and that's normally found in the intermediate CA's 
certificate.

[Santosh; Amen]

I suppose that if an intermediate CA has a certificate from 
which it's hard to find the CRL (e.g. a certificate with no distribution 
point address or with only a DN as specification) a pointer from each 
certificate it issues could be useful.  However, this would naturally go 
into the AIA extension (since it references information about the issuer 
of the certificate) rather than into SIA, and it would have to be of lower 
precedence than an AIA or DP in the issuer certificate itself since the CA 
MUST not be able to override a revocation of its certificate.  Is 
permitting a CA to do this really a good idea, and if so is it worthwhile?

[Santosh: You can always define new extensions or add fields and options to
existing extensions.  But, that is not there.  You should talk with the
3280bis editors if you want to have a capability in SIA or AIA to point to
CRL.]

Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
11/11/2005 07:29 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: RFC-3280 [Subject Information Access]

And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [email-masked]
Subject: RFC-3280 [Subject Information Access]

Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using the 
Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there 
could
address a CRL or Certs repository or other services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates 
repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

                 Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [email-masked]
                                                 Tel.:   +39 (0)11  564 
7081
http://security.polito.it                       Fax:    +39   178  270 
2077
                                                 Mobile: +39 (0)347 7222 
365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  
http://ca.polito.it
Authority's Certificate:          
http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              
http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

Date: Sat, 12 Nov 2005 17:54:04 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College
To: pkix <[email-masked]>
CC: Tom Gindin <[email-masked]>
Subject: Re: RFC-3280 [Subject Information Access]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080608000000000609030908
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Gindin wrote:
>         Santosh, Massimiliano:
> 
>         I'm confused by the way in which one would enable "a CA to specify 
> its own (not its issuer's) CRL distribution point in its certificate". 
> Does this mean the distribution point covering the CA (which should 
> already be in the certificate issued to this CA) or a distribution point 
> containing a CRL created by the CA (which gets put into the CRL DP of a 
> certificate it creates)?  And does it go into a certificate issued to the 
> CA by another CA (in which case it can't be specified in this way), a 
> certificate issued by the CA to somebody else (the purpose for which CRL 
> DP's were designed, unless it's a CRL covering the CA), or a rollover 
> self-issued certificate?

Now I am confused... sorry I did not get your question. Let me explain by
using an example:

	rootCA -> CA1 -> CA2 -> UserCert

In this case the CRL Distribution Point extension will carry pointers to:
* If in the user cert -> to the CRL issued by CA2
* If in the CA2 cert -> to the CRL issued by CA1
* If in the rootCA cert -> to the CRL issued by the issuer of rootCA, which
   is equivalent to the subject, therefor (this is my guess) you can put there
   the pointer to the CRL issued by rootCA

My problem is: how do I find the CRL issued by CA2 without having to retrieve
a UserCert (or a cert issued by CA2) ? I guess there is no way to do such a
thing at the moment... am I wrong ?

>         A relying party certainly needs to have revocation information for 
> an intermediate CA, and that's normally found in the intermediate CA's 
> certificate.  I suppose that if an intermediate CA has a certificate from 
> which it's hard to find the CRL (e.g. a certificate with no distribution 
> point address or with only a DN as specification) a pointer from each 
> certificate it issues could be useful.  However, this would naturally go 
> into the AIA extension (since it references information about the issuer 
> of the certificate) rather than into SIA, and it would have to be of lower

Indeed, my point was : how to search for a CRL issued by CA1 provided you
only have CA1 cert ? This should go into SIA, not AIA...

> precedence than an AIA or DP in the issuer certificate itself since the CA 
> MUST not be able to override a revocation of its certificate.  Is 
> permitting a CA to do this really a good idea, and if so is it worthwhile?

No, probably there is a misunderstanding here. What I was proposing was not
to change AIA or CDP contents, instead to provide a specific extension to
point to CRLs issued by the "current" CA cert (not by its issuer). This
has a different purpose than searching for revocation information for the
"current" certificate; I want a pointer to revocation information provided
by the "current" certificate...

I hope I clarified a bit what I was really asking... :-D

Let me know,

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062 (Sudikoff)	    Office Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

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

--------------ms080608000000000609030908--

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: RFC-3280 [Subject Information Access]
From: Tom Gindin <[email-masked]>
Date: Sat, 12 Nov 2005 16:04:43 -0500
Sender: [email-masked]

        Santosh, Massimiliano:

        I'm confused by the way in which one would enable "a CA to specify 
its own (not its issuer's) CRL distribution point in its certificate". 
Does this mean the distribution point covering the CA (which should 
already be in the certificate issued to this CA) or a distribution point 
containing a CRL created by the CA (which gets put into the CRL DP of a 
certificate it creates)?  And does it go into a certificate issued to the 
CA by another CA (in which case it can't be specified in this way), a 
certificate issued by the CA to somebody else (the purpose for which CRL 
DP's were designed, unless it's a CRL covering the CA), or a rollover 
self-issued certificate?
        A relying party certainly needs to have revocation information for 
an intermediate CA, and that's normally found in the intermediate CA's 
certificate.  I suppose that if an intermediate CA has a certificate from 
which it's hard to find the CRL (e.g. a certificate with no distribution 
point address or with only a DN as specification) a pointer from each 
certificate it issues could be useful.  However, this would naturally go 
into the AIA extension (since it references information about the issuer 
of the certificate) rather than into SIA, and it would have to be of lower 
precedence than an AIA or DP in the issuer certificate itself since the CA 
MUST not be able to override a revocation of its certificate.  Is 
permitting a CA to do this really a good idea, and if so is it worthwhile?

Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
11/11/2005 07:29 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: RFC-3280 [Subject Information Access]

And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [email-masked]
Subject: RFC-3280 [Subject Information Access]

Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using the 
Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there 
could
address a CRL or Certs repository or other services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates 
repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

                 Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [email-masked]
                                                 Tel.:   +39 (0)11  564 
7081
http://security.polito.it                       Fax:    +39   178  270 
2077
                                                 Mobile: +39 (0)347 7222 
365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  
http://ca.polito.it
Authority's Certificate:          
http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              
http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC-3280 [Subject Information Access]
Date: Fri, 11 Nov 2005 07:29:59 -0500
Importance: Normal
Sender: [email-masked]

And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [email-masked]
Subject: RFC-3280 [Subject Information Access]

Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using the Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there could
address a CRL or Certs repository or other services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [email-masked]
                                                 Tel.:   +39 (0)11  564 7081
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: +39 (0)347 7222 365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

Date: Fri, 11 Nov 2005 00:15:53 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Politecnico di Torino
To: [email-masked]
Subject: RFC-3280 [Subject Information Access]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030303090006000509010605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using
the Subject Information Access with id-ad-caRepository as accessMethod.
The problem is that its definition is too broad, therefore the URI I
can put in there could address a CRL or Certs repository or other
services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [email-masked]
                                                 Tel.:   +39 (0)11  564 7081
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: +39 (0)347 7222 365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

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

Mg2LU2waYg5t/59gLr86QbsAAAAAAAA--------------ms030303090006000509010605--

Date: Thu, 10 Nov 2005 14:45:50 +0100
From: Peter Sylvester <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft minutes (SCVP part)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070605070908040502050701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

SCVP-21 was made as a result of a discussion of one hour between Tim, 
Denis and me, where
Tim took notes.

During three months there was no exchange to clarify anything. one week 
before
the deadline of the submission we were informed about an editors draft 
and had three
days to comment, the obvious thing was that several points were 
misunderstood
or that the authors were afraid to change something, or they referred to 
existing
implementations, etc. Nothing, really nothing to explain what is wrong, 
in particular
when some requests have been partially treated and retreated in the past.
I don't think that it is unfair to ask why the authors (who are as I 
understand not implementors)
continue to find arguments other than technical to refuse request which they
technically already admit as useful, ending with a remark

Given the tone and content of your message, I have finally recognized that you 
will never be happy with SCVP (or any document I am involved with.)  You are 
clearly determined to disagree with whatever is in the specification, so I have 
given up on addressing your comments.  There are far too many demands on my time 
for such wasted effort.  I have got to concentrate my efforts where they have 
*some* chance of success.

SCVP 21 finally after years of pointing to the requirement
a server can return another SCVP response. Good.

There is the n-th iterator of changed handling identities in the request 
and
response, resulting this time in a respondername in a request,
the encodings and semantics of the fields were changed
from octet strings to generalname, good, but, I did only see recently
that two drafts ago an already existing responder identity in the request
was removed.

It is not very pleasing to see, first, total rejection, then partial 
support,
then a bit more, then partial removal, etc. It may be that my request
is totally uninterpretable or what?

Peter

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autoritÃ©; 
die Liste mit zurÃ¼ckgerufenen Zertifikaten finden Sie da auch. 

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

URUK9fHhkx8AAAAAAAA--------------ms070605070908040502050701--

Date: Wed, 9 Nov 2005 16:28:18 -0500
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft minutes (SCVP part)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter,

I reread your message and realize that when you used the phrase "... 
the notes taken by Tim Polk ..." you were not referring to the 
meeting minutes. My error. I had assumed you were, because the 
message was sent with a subject line of "draft minutes (SCVP part)."

>...
>Do you want me to resend?
>
I would like the material I requested in the private message re SCVP, 
sent a a private response. The 6 points in your message don't follow 
the format of what I requested, i.e., reference to section of 
SCVP-21, explanation of why is is not compliant with 3379 OR with a 
request that you or Denis made in subsequent messages. None of the 
points references a section number in SCVP-21, nor provides cross 
references to 3379, for example.

steve

Date: Wed, 09 Nov 2005 12:00:12 +0100
From: Peter Sylvester <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft minutes (SCVP part)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080704030206020704070507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Stephen Kent wrote:

> Peter,
>
> First, I am the editor of the minutes, not Tim.

Did I say that?

>
> I'm afraid that your comments are not germane to the meeting minutes, 
> the primary goal of which is to accurately represent what was said by 
> the presenters and WG attendees in the course of the meeting. 
> Objective, factual errors related to what was said are valid a basis 
> for comments on meeting minutes. However, a detailed debate about a 
> contentious issue like this is not appropriate for meeting minute 
> comments & corrections.

Indeed, this is not a comment for minutes.

Throw into a black hole, wait until they evaporate as a part of
the detailed discussion. You have asked in a private message
to send a comment, you may thus just consider that I have forgotten
to change the comment into something more appropriate and that
I used the minutes as a starting point.

Do you want me to resend?

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autoritÃ©; 
die Liste mit zurÃ¼ckgerufenen Zertifikaten finden Sie da auch. 

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

VaAuWEzeNgwAAAAAAAA--------------ms080704030206020704070507--

Date: Tue, 8 Nov 2005 21:24:51 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG meeting presentations now posted
Sender: [email-masked]

https://onsite.ietf.org/public/meeting_materials.cgi?meeting_numd

Date: Tue, 8 Nov 2005 15:32:28 -0500
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft minutes (SCVP part)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter,

First, I am the editor of the minutes, not Tim.

I'm afraid that your comments are not germane to the meeting minutes, 
the primary goal of which is to accurately represent what was said by 
the presenters and WG attendees in the course of the meeting. 
Objective, factual errors related to what was said are valid a basis 
for comments on meeting minutes. However, a detailed debate about a 
contentious issue like this is not appropriate for meeting minute 
comments & corrections.

Steve

Date: Tue, 08 Nov 2005 20:38:44 +0100
From: Peter Sylvester <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft minutes (SCVP part)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090104030100020405010305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Stephen Kent wrote:

> Please send me a message with any requested corrections before 11/28:
>
> Steve
> -----
>
>
> PKIX WG Meeting 11/7/05
>
> Edited by Steve Kent
>
>
>
> SCVP rev 21- David Cooper (NIST)
>        Text was added to clarify conformance requirements. WantBack 
> items were made optional. New, optional items were added to allow an 
> SCVP server to relay responses from other SCVP servers, and to label 
> responses with an identity specified by a requestor, if the server has 
> multiple identities. The reference to validation policies was 
> tightened, so that only OIDs, not URIs, are accepted. Policy 
> parameters, in addition to validation algorithm parameters, are now 
> supported, but the optional validation policy attributes were removed, 
> since no examples have been provided and the need for this facility 
> was not well established.

The authors have spend three months to get out an editors after the 
Paris meeting and
after Denis and me spend an hour to explain Tim Polk our issues. During 
the following
months that was no interaction, and  just a week before the submission 
deadline, there
was a editors draft shown to us to comment it within three days. This 
draft showed that
the notes taken by Tim Polk do not reflect the issues, and, not 
surprisong, they were either
ignored or only partially interpreted.

The mentioned 'server has multiple identities' has never been stated as 
such, and the requested
implementation (something which I have been asking for since years) is 
continuously misunderstood,
either refused, then partially implement, and then withdrawn.

Point 1:

What I have been requesting is that the CVrequest, and the CVResponse 
carry two sequences
of identifiers for the requestors and the responders.

For the CVRequest, the requestorName sequence indicates who is acting as 
client or for whom
the client is acting. A server may use the list to determine whether one 
of the authentication
methods matches with one of the entities.

For the CVRequest, the responderName sequence indicates who the client 
believs should participate
in the response. (this seems to be close to the current text). But the 
indication should be
a list, in order to allow for proxies chaining or other. it is up to the 
server to determine
what to do with the field, and how to respond with an appropriate 
authentication method.

For the CVResponse, the the requestorName sequence is essentially a copy 
of the last CVrequest
(e.g. if chaining was used). The server may add an identification, if 
the initial client has not
provide one, and if it can be derived from a networking identification 
or an authentication method,
all this controlled by a policy where a client can be allowed to stay 
anonymous through a proxy.

For the CVResponse, the the responderName sequence (a responder field 
had been introduced in the
past and then removed again), indicates the identities of parties that 
have participated in the
creation of the response. This allows a client to show them immediately 
without the need of
interpreting the details of the result which is difficult if not 
impossible in case of muiltiple
identities of servers.

The various drafts cover all this partially, but each time only a part, 
a different one.

Or,  in

    CVRequest ::= SEQUENCE {
      cvRequestVersion        INTEGER DEFAULT 1,
      query                   Query,
      requestorRef        [0] GeneralNames OPTIONAL,
      requestNonce        [1] OCTET STRING OPTIONAL,
      requestorName       [2] GeneralName OPTIONAL,
      responderName       [3] GeneralName OPTIONAL,
      requestExtensions   [4] Extensions OPTIONAL }

   CVResponse ::= SEQUENCE {
      cvResponseVersion         INTEGER,
      serverConfigurationID     INTEGER,
      producedAt                GeneralizedTime,
      responseStatus            ResponseStatus,
      respValidationPolicy  [0] RespValidationPolicy OPTIONAL,
      requestRef            [1] RequestReference OPTIONAL,
      requestorRef          [2] GeneralNames OPTIONAL,
      requestorName         [3] GeneralNames OPTIONAL,
      replyObjects          [4] ReplyObjects OPTIONAL,
      respNonce             [5] OCTET STRING OPTIONAL,
      serverContextInfo     [6] OCTET STRING OPTIONAL,
      cvResponseExtensions  [7] Extensions OPTIONAL }

there should be

      requestorName         [x] GeneralNames OPTIONAL,
      responderName         [y] GeneralNames OPTIONAL,

(There was once a responder in the response structure.)

Point 2:

I have asked to explain the need for the  MUST concerning

 If the default values for all of the flags are used, then the
  response flags item MUST NOT be included in the request.

    responseFlags           ResponseFlags OPTIONAL,

you can have the same effect using

    responseFlags           ResponseFlags DEFAULT {} ,

(modulo syntax errors introduced by my limited knowledge).

i.e. a MUST important for interop test is replaced by a standard feature 
of ASN.1

My suggestion of  'elegance', i.e. the one that I made a strawman in Paris
was to change the definition of

    ResponseFlags ::= SEQUENCE {
      fullRequestInResponse      [0] BOOLEAN DEFAULT FALSE,
      responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
      protectResponse            [2] BOOLEAN DEFAULT TRUE,
      cachedResponse             [3] BOOLEAN DEFAULT TRUE }

to a bitstring with named values, and thus avoiding nested DEFAULT specs.
I can live with that, just write the DEFAULT as indicated above, and you 
have one
test les for interop. On the other hand, there are compilers that may have
problems with nested defaults. so

    ResponseFlags ::= BIT STRING {
      fullRequestInResponse(0),         responseValidationPolByRef(1)
      protectResponse(2)
      cachedResponse (3) }

and an appropriate DEFAULT 
(responseValidationPolByRef,protectResponse,cachedResponse)
or DEFAULT '0111'B

I repeat, the original point is the MUST about the empty sequence 
implying an
unncessary addition explicit test for conformance which you can handle by a
spec of DEFAULT { }.

point 3;

After 2 years or so, none of the authors ever answered why there is:

ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

    ReplyWantBack::= SEQUENCE {
      wb                         OBJECT IDENTIFIER,
      value                      OCTET STRING }

where some of the octet strings contain certificat lists and crls for 
example.
What is the security risk or advantage to force client to invoke a parser
individually each time.

I simply propose:

    ReplyWantBack::= SEQUENCE {
      wbType                       OBJECT IDENTIFIER,
      wbValue                      ANY DEFINED BY wbType }

(or in fact the correct corresponding current ASN.1 which may be a
bit difficult to understand for some people.)

There are minimal changes in the text that follows this definition, i.e.
instead of saying the octet string contains you says the type used is ...

Compare this with a similar construct in the request.

    RevocationInfo ::= CHOICE {
      crl                    [0] CertificateList,
      delta-crl              [1] CertificateList,
      ocsp                   [2] OCSPResponse,
      other                  [3] OtherRevInfo }

    OtherRevInfo ::= SEQUENCE {
      riType                     OBJECT IDENTIFIER,
      riValue                    ANY DEFINED BY riType }

Point 4:

Use current ASN1. Free tools to validate the syntax exist.

Point 5:
Policy issues: I leave this mainly to Denis, but IMO the policy definitions
are intended to be usable for a client to determine *ALL* the required 
or possible
parameters. By no way it is acceptable that a client try be required to 
make
a trial to detrmline whether a something is necessary or required. Otherwise
the whole point of having a protocol for policy discovery is useless.

Point 6:

Since this is ther from the very beginning, some error codes are represented
as integer, although one would rather use an enumeration. Integers are
for values that be be used for counting. But well, I won't die because 
of that.

>
> The one remaining problem here is how to make this protocol agile with 
> regard to the hash algorithm employed for certificate references. 
> Today SHA-1 is hardwired. Updating the spec to specify another hash 
> function does not satisfy the new algorithm agility requirement. Steve 
> Kent suggested that the hash function can be an aspect of the server's 
> validation policy, to satisfy the agility requirement. Russ Housley 
> suggested that the OID of the hash employed be explicitly returned, in 
> case the server's policy changes over time (but the policy OID does 
> not). A straw poll was conducted to get a sense of the room for the 
> two alternatives described in the last slide in this presentation. The 
> first alternative received 12 votes, vs. 0 for the second. (Slides)

Why are these alternatives?

A client should be able to detect CURRENT hash algorithm in a policy 
lookup.

A server response and request are self containing entities. No 
additional information
should be required to interprete the content, in particular, it an octet 
string containing
a hash always needs to be accompanied by an algorithm identifier (unless 
the the protocol
or version specific default is used.

Peter

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

SvOvawCwBXwAAAAAAAA--------------ms090104030100020405010305--

Date: Tue, 08 Nov 2005 19:36:41 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: OCSP revision
Sender: [email-masked]

Carl Wallace wrote:

> At the meeting yesterday, OCSP revisions to address algorithm agility were
> discussed.  Since the doc is being revised, I suggest an extension or field
> be added to enable clients to ask the responder to include the responder's
> certificate in the response (similar to the certReq field in RFC3161).  
> 

Could other OCSP revisions be incorporated at the same time or just
"algorithm agility"?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: OCSP revision
Date: Tue, 8 Nov 2005 13:52:20 -0500
Sender: [email-masked]

At the meeting yesterday, OCSP revisions to address algorithm agility were
discussed.  Since the doc is being revised, I suggest an extension or field
be added to enable clients to ask the responder to include the responder's
certificate in the response (similar to the certReq field in RFC3161).  

Date: Mon, 7 Nov 2005 16:03:57 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft minutes
Sender: [email-masked]

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

Please send me a message with any requested corrections before 11/28:

Steve
-----

PKIX WG Meeting 11/7/05

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]> & Tim Polk <[email-masked]>

The PKIX WG met once during the 64th IETF. A total of approximately 
45 individuals participated in the meeting.

Document status - Tim Polk (NIST)
Three RFCs just issued: 4158, 4210, and 4211.
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis, 
and CRL AIA.
Two documents with the ADs: AC Policies & PKIX Repository Locator.
Other documents:
-	SIM is undergoing revisions to address WG co-chair comments 
before being forwarded to the IESG.
-	The authors are being asked to create a matrix
-	A new version of 3280bis will be submitted after this meeting.
-	The WG chairs have requested a new version of the GOST 
algorithms to be posted, before initiating a last call
(Slides)

PKIX WG Document Presentations

RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk)
Last call will be initiated for all three after this meeting. Updates 
include features to support SIM certificate requests. (Slides)

SCVP rev 21- David Cooper (NIST)
	Text was added to clarify conformance requirements. WantBack 
items were made optional. New, optional items were added to allow an 
SCVP server to relay responses from other SCVP servers, and to label 
responses with an identity specified by a requestor, if the server 
has multiple identities. The reference to validation policies was 
tightened, so that only OIDs, not URIs, are accepted. Policy 
parameters, in addition to validation algorithm parameters, are now 
supported, but the optional validation policy attributes were 
removed, since no examples have been provided and the need for this 
facility was not well established.

The one remaining problem here is how to make this protocol agile 
with regard to the hash algorithm employed for certificate 
references. Today SHA-1 is hardwired. Updating the spec to specify 
another hash function does not satisfy the new algorithm agility 
requirement. Steve Kent suggested that the hash function can be an 
aspect of the server's validation policy, to satisfy the agility 
requirement. Russ Housley suggested that the OID of the hash employed 
be explicitly returned, in case the server's policy changes over time 
(but the policy OID does not). A straw poll was conducted to get a 
sense of the room for the two alternatives described in the last 
slide in this presentation. The first alternative received 12 votes, 
vs. 0 for the second. (Slides)

SHA-1 Collisions & OCSP - Russ Housley (Vigil Security)
	 Based on the recent NIST hash workshop, Russ suggests that 
we begin making plans to move away from  SHA-1, with a 2010 target 
for transition. NIST will begin work on a successor to SHA-256, but a 
new algorithm may be 5 years away. The only good alternative now is 
SHA-256.

	From an algorithm agility perspective, OCSP request/response 
exchange needs to provide a way for the requestor to know which 
algorithms the responder (server) supports. This could be supported 
by adding a new protocol to negotiate the hash algorithm prior to 
entering into the OCSP exchange. Alternatively, the responder's 
certificate could have an extension that specified supported hash 
algorithms. This also might be addressed via configuration at the 
requestor, although this is problematic given the intent of changing 
the algorithm twice over the next 10 years. Russ suggests a request 
extension that allows the requestor to specify which hash functions 
(and signature algorithms) it supports. There is still a need to 
select one of the three approaches cited above, to allow a requestor 
to determine which algorithms are supported by the responder.

	Russ suggests that the WG find volunteers to update OCSP, and 
to examine other PKIX protocols to determine whether they exhibit 
similar problems and, if so, how to fix them. Stephen Farrell asks 
whether there may be a way to solve this problem more generically, 
rather than engineering a solution for each protocol in PKIX, and in 
other WGs.  (Slides)

SHA-2 Support in PKIX - Tim Polk (NIST)
        We currently specify how to use SHA-2 (SHA-256 & SHA-512) for 
RSA (RFC 4055), but not for DSA or EC-DSA. Tim suggests that two new 
drafts be generated, one for DSA and one for ECDSA, because the two 
algorithms are at different stages of NIST publication. NIST has 
volunteered to write these two drafts, but additional co-editors are 
welcome. (Slides)

Service Names as Subject Alt Names - Stefan Santesson (Microsoft)
       The draft has been revised since its initial version. It no 
longer is bound as tightly to the DNS SRV record example. The 
assumption here is that the user (host) knows the service name and 
domain name and determines whether the server to which it connects is 
appropriate, based on the server's certificate. Steve Kent suggests 
that we need to revisit the security implications of use of this 
facility, given the revised definition of the use model. Stefan 
suggests that use of name constraints for this extension may be 
appropriate. Since the string comparison is against the locally 
configured service name, not the DNS SRV string, UTF8 seems to be the 
right encoding choice. (Slides)

Related Specifications & Liaison Presentations

Carl Wallace (Orion Security) - LTANS WG status
	LTANS is meeting the same day (in the same room) at this 
IETF. Carl requests review by PKIX WG members of the evidence record 
I-D and an archive protocol I-D from LTANS. Note potential 
relationships between SCVP and LTNANS work.  (no slides)
--======_-1080720781=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft minutes</title></head><body>
<div>Please send me a message with any requested corrections before
11/28:</div>
<div><br></div>
<div>Steve</div>
<div>-----</div>
<div><br></div>
<div><font face="Times New Roman" size="+1" color="#000000"><br>
</font><font color="#000000">PKIX WG Meeting 11/7/05<br>
<br>
Edited by Steve Kent<br>
<br>
Chairs: Stephen Kent &lt;[email-masked]&gt; &amp; Tim Polk
&lt;[email-masked]&gt;<br>
<br>
The PKIX WG met once during the 64th IETF. A total of approximately 45
individuals participated in the meeting.<br>
<br>
<br>
Document status - Tim Polk (NIST)<br>
Three RFCs just issued: 4158, 4210, and 4211.<br>
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis,
and CRL AIA.<br>
Two documents with the ADs: AC Policies &amp; PKIX Repository
Locator.<br>
Other documents:<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp; </x-tab></font>SIM is
undergoing revisions to address WG co-chair comments before being
forwarded to the IESG.<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab></font>The authors are being asked to create a matrix<br>
-<font face="Arial"><x-tab> </x-tab></font>A new version of 3280bis
will be submitted after this meeting.<br>
-<font face="Arial"><x-tab> </x-tab></font>The WG chairs have
requested a new version of the GOST algorithms to be posted, before
initiating a last call<br>
(Slides)<br>
<br>
<br>
PKIX WG Document Presentations<br>
<br>
<br>
RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring
Hawk)<br>
Last call will be initiated for all three after this meeting. Updates
include features to support SIM certificate requests. (Slides)<br>
<br>
<br>
SCVP rev 21- David Cooper (NIST)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Text was added to
clarify conformance requirements. WantBack items were made optional.
New, optional items were added to allow an SCVP server to relay
responses from other SCVP servers, and to label responses with an
identity specified by a requestor, if the server has multiple
identities. The reference to validation policies was tightened, so
that only OIDs, not URIs, are accepted. Policy parameters, in addition
to validation algorithm parameters, are now supported, but the
optional validation policy attributes were removed, since no examples
have been provided and the need for this facility was not well
established.<br>
<br>
The one remaining problem here is how to make this protocol agile with
regard to the hash algorithm employed for certificate references.
Today SHA-1 is hardwired. Updating the spec to specify another hash
function does not satisfy the new algorithm agility requirement. Steve
Kent suggested that the hash function can be an aspect of the server's
validation policy, to satisfy the agility requirement. Russ Housley
suggested that the OID of the hash employed be explicitly returned, in
case the server's policy changes over time (but the policy OID does
not). A straw poll was conducted to get a sense of the room for the
two alternatives described in the last slide in this presentation. The
first alternative received 12 votes, vs. 0 for the second.
(Slides)<br>
&nbsp;&nbsp;&nbsp;<br>
<br>
SHA-1 Collisions &amp; OCSP - Russ Housley (Vigil Security)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab> Based on the recent NIST hash
workshop, Russ suggests that we begin making plans to move away from&nbsp;
SHA-1, with a 2010 target for transition. NIST will begin work on a
successor to SHA-256, but a new algorithm may be 5 years away. The
only good alternative now is SHA-256.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>From an algorithm
agility perspective, OCSP request/response exchange needs to provide a
way for the requestor to know which algorithms the responder (server)
supports. This could be supported by adding a new protocol to
negotiate the hash algorithm prior to entering into the OCSP exchange.
Alternatively, the responder's certificate could have an extension
that specified supported hash algorithms. This also might be addressed
via configuration at the requestor, although this is problematic given
the intent of changing the algorithm twice over the next 10 years.
Russ suggests a request extension that allows the requestor to specify
which hash functions (and signature algorithms) it supports. There is
still a need to select one of the three approaches cited above, to
allow a requestor to determine which algorithms are supported by the
responder.<br>
<br>
<x-tab> </x-tab>Russ suggests that the WG find volunteers to update
OCSP, and to examine other PKIX protocols to determine whether they
exhibit similar problems and, if so, how to fix them. Stephen Farrell
asks whether there may be a way to solve this problem more
generically, rather than engineering a solution for each protocol in
PKIX, and in other WGs.&nbsp; (Slides)</font></div>
<div><font color="#000000"><br>
<br>
SHA-2 Support in PKIX - Tim Polk (NIST)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We currently specify how to use
SHA-2 (SHA-256 &amp; SHA-512) for RSA (RFC 4055), but not for DSA or
EC-DSA. Tim suggests that two new drafts be generated, one for DSA and
one for ECDSA, because the two algorithms are at different stages of
NIST publication. NIST has volunteered to write these two drafts, but
additional co-editors are welcome. (Slides)<br>
&nbsp;&nbsp;<br>
<br>
Service Names as Subject Alt Names - Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The draft has been revised since its
initial version. It no longer is bound as tightly to the DNS SRV
record example. The assumption here is that the user (host) knows the
service name and domain name and determines whether the server to
which it connects is appropriate, based on the server's certificate.
Steve Kent suggests that we need to revisit the security implications
of use of this facility, given the revised definition of the use
model. Stefan suggests that use of name constraints for this extension
may be appropriate. Since the string comparison is against the locally
configured service name, not the DNS SRV string, UTF8 seems to be the
right encoding choice. (Slides)<br>
<br>
<br>
Related Specifications &amp; Liaison Presentations<br>
<br>
Carl Wallace (Orion Security) - LTANS WG status<br>
<x-tab> </x-tab>LTANS is meeting the same day (in the same room) at
this IETF. Carl requests review by PKIX WG members of the evidence
record I-D and an archive protocol I-D from LTANS. Note potential
relationships between SCVP and LTNANS work.&nbsp; (no
slides)</font></div>
</body>
</html>
--======_-1080720781=_ma======--

Date: Mon, 7 Nov 2005 16:03:57 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft minutes
Sender: [email-masked]

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

Please send me a message with any requested corrections before 11/28:

Steve
-----

PKIX WG Meeting 11/7/05

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]> & Tim Polk <[email-masked]>

The PKIX WG met once during the 64th IETF. A total of approximately 
45 individuals participated in the meeting.

Document status - Tim Polk (NIST)
Three RFCs just issued: 4158, 4210, and 4211.
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis, 
and CRL AIA.
Two documents with the ADs: AC Policies & PKIX Repository Locator.
Other documents:
-	SIM is undergoing revisions to address WG co-chair comments 
before being forwarded to the IESG.
-	The authors are being asked to create a matrix
-	A new version of 3280bis will be submitted after this meeting.
-	The WG chairs have requested a new version of the GOST 
algorithms to be posted, before initiating a last call
(Slides)

PKIX WG Document Presentations

RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk)
Last call will be initiated for all three after this meeting. Updates 
include features to support SIM certificate requests. (Slides)

SCVP rev 21- David Cooper (NIST)
	Text was added to clarify conformance requirements. WantBack 
items were made optional. New, optional items were added to allow an 
SCVP server to relay responses from other SCVP servers, and to label 
responses with an identity specified by a requestor, if the server 
has multiple identities. The reference to validation policies was 
tightened, so that only OIDs, not URIs, are accepted. Policy 
parameters, in addition to validation algorithm parameters, are now 
supported, but the optional validation policy attributes were 
removed, since no examples have been provided and the need for this 
facility was not well established.

The one remaining problem here is how to make this protocol agile 
with regard to the hash algorithm employed for certificate 
references. Today SHA-1 is hardwired. Updating the spec to specify 
another hash function does not satisfy the new algorithm agility 
requirement. Steve Kent suggested that the hash function can be an 
aspect of the server's validation policy, to satisfy the agility 
requirement. Russ Housley suggested that the OID of the hash employed 
be explicitly returned, in case the server's policy changes over time 
(but the policy OID does not). A straw poll was conducted to get a 
sense of the room for the two alternatives described in the last 
slide in this presentation. The first alternative received 12 votes, 
vs. 0 for the second. (Slides)

SHA-1 Collisions & OCSP - Russ Housley (Vigil Security)
	 Based on the recent NIST hash workshop, Russ suggests that 
we begin making plans to move away from  SHA-1, with a 2010 target 
for transition. NIST will begin work on a successor to SHA-256, but a 
new algorithm may be 5 years away. The only good alternative now is 
SHA-256.

	From an algorithm agility perspective, OCSP request/response 
exchange needs to provide a way for the requestor to know which 
algorithms the responder (server) supports. This could be supported 
by adding a new protocol to negotiate the hash algorithm prior to 
entering into the OCSP exchange. Alternatively, the responder's 
certificate could have an extension that specified supported hash 
algorithms. This also might be addressed via configuration at the 
requestor, although this is problematic given the intent of changing 
the algorithm twice over the next 10 years. Russ suggests a request 
extension that allows the requestor to specify which hash functions 
(and signature algorithms) it supports. There is still a need to 
select one of the three approaches cited above, to allow a requestor 
to determine which algorithms are supported by the responder.

	Russ suggests that the WG find volunteers to update OCSP, and 
to examine other PKIX protocols to determine whether they exhibit 
similar problems and, if so, how to fix them. Stephen Farrell asks 
whether there may be a way to solve this problem more generically, 
rather than engineering a solution for each protocol in PKIX, and in 
other WGs.  (Slides)

SHA-2 Support in PKIX - Tim Polk (NIST)
        We currently specify how to use SHA-2 (SHA-256 & SHA-512) for 
RSA (RFC 4055), but not for DSA or EC-DSA. Tim suggests that two new 
drafts be generated, one for DSA and one for ECDSA, because the two 
algorithms are at different stages of NIST publication. NIST has 
volunteered to write these two drafts, but additional co-editors are 
welcome. (Slides)

Service Names as Subject Alt Names - Stefan Santesson (Microsoft)
       The draft has been revised since its initial version. It no 
longer is bound as tightly to the DNS SRV record example. The 
assumption here is that the user (host) knows the service name and 
domain name and determines whether the server to which it connects is 
appropriate, based on the server's certificate. Steve Kent suggests 
that we need to revisit the security implications of use of this 
facility, given the revised definition of the use model. Stefan 
suggests that use of name constraints for this extension may be 
appropriate. Since the string comparison is against the locally 
configured service name, not the DNS SRV string, UTF8 seems to be the 
right encoding choice. (Slides)

Related Specifications & Liaison Presentations

Carl Wallace (Orion Security) - LTANS WG status
	LTANS is meeting the same day (in the same room) at this 
IETF. Carl requests review by PKIX WG members of the evidence record 
I-D and an archive protocol I-D from LTANS. Note potential 
relationships between SCVP and LTNANS work.  (no slides)
--======_-1080723712=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>draft minutes</title></head><body>
<div>Please send me a message with any requested corrections before
11/28:</div>
<div><br></div>
<div>Steve</div>
<div>-----</div>
<div><br></div>
<div><font face="Times New Roman" size="+1" color="#000000"><br>
</font><font color="#000000">PKIX WG Meeting 11/7/05<br>
<br>
Edited by Steve Kent<br>
<br>
Chairs: Stephen Kent &lt;[email-masked]&gt; &amp; Tim Polk
&lt;[email-masked]&gt;<br>
<br>
The PKIX WG met once during the 64th IETF. A total of approximately 45
individuals participated in the meeting.<br>
<br>
<br>
Document status - Tim Polk (NIST)<br>
Three RFCs just issued: 4158, 4210, and 4211.<br>
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis,
and CRL AIA.<br>
Two documents with the ADs: AC Policies &amp; PKIX Repository
Locator.<br>
Other documents:<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp; </x-tab></font>SIM is
undergoing revisions to address WG co-chair comments before being
forwarded to the IESG.<br>
-<font face="Arial"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab></font>The authors are being asked to create a matrix<br>
-<font face="Arial"><x-tab> </x-tab></font>A new version of 3280bis
will be submitted after this meeting.<br>
-<font face="Arial"><x-tab> </x-tab></font>The WG chairs have
requested a new version of the GOST algorithms to be posted, before
initiating a last call<br>
(Slides)<br>
<br>
<br>
PKIX WG Document Presentations<br>
<br>
<br>
RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring
Hawk)<br>
Last call will be initiated for all three after this meeting. Updates
include features to support SIM certificate requests. (Slides)<br>
<br>
<br>
SCVP rev 21- David Cooper (NIST)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Text was added to
clarify conformance requirements. WantBack items were made optional.
New, optional items were added to allow an SCVP server to relay
responses from other SCVP servers, and to label responses with an
identity specified by a requestor, if the server has multiple
identities. The reference to validation policies was tightened, so
that only OIDs, not URIs, are accepted. Policy parameters, in addition
to validation algorithm parameters, are now supported, but the
optional validation policy attributes were removed, since no examples
have been provided and the need for this facility was not well
established.<br>
<br>
The one remaining problem here is how to make this protocol agile with
regard to the hash algorithm employed for certificate references.
Today SHA-1 is hardwired. Updating the spec to specify another hash
function does not satisfy the new algorithm agility requirement. Steve
Kent suggested that the hash function can be an aspect of the server's
validation policy, to satisfy the agility requirement. Russ Housley
suggested that the OID of the hash employed be explicitly returned, in
case the server's policy changes over time (but the policy OID does
not). A straw poll was conducted to get a sense of the room for the
two alternatives described in the last slide in this presentation. The
first alternative received 12 votes, vs. 0 for the second.
(Slides)<br>
&nbsp;&nbsp;&nbsp;<br>
<br>
SHA-1 Collisions &amp; OCSP - Russ Housley (Vigil Security)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab> Based on the recent NIST hash
workshop, Russ suggests that we begin making plans to move away from&nbsp;
SHA-1, with a 2010 target for transition. NIST will begin work on a
successor to SHA-256, but a new algorithm may be 5 years away. The
only good alternative now is SHA-256.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>From an algorithm
agility perspective, OCSP request/response exchange needs to provide a
way for the requestor to know which algorithms the responder (server)
supports. This could be supported by adding a new protocol to
negotiate the hash algorithm prior to entering into the OCSP exchange.
Alternatively, the responder's certificate could have an extension
that specified supported hash algorithms. This also might be addressed
via configuration at the requestor, although this is problematic given
the intent of changing the algorithm twice over the next 10 years.
Russ suggests a request extension that allows the requestor to specify
which hash functions (and signature algorithms) it supports. There is
still a need to select one of the three approaches cited above, to
allow a requestor to determine which algorithms are supported by the
responder.<br>
<br>
<x-tab> </x-tab>Russ suggests that the WG find volunteers to update
OCSP, and to examine other PKIX protocols to determine whether they
exhibit similar problems and, if so, how to fix them. Stephen Farrell
asks whether there may be a way to solve this problem more
generically, rather than engineering a solution for each protocol in
PKIX, and in other WGs.&nbsp; (Slides)</font></div>
<div><font color="#000000"><br>
<br>
SHA-2 Support in PKIX - Tim Polk (NIST)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; We currently specify how to use
SHA-2 (SHA-256 &amp; SHA-512) for RSA (RFC 4055), but not for DSA or
EC-DSA. Tim suggests that two new drafts be generated, one for DSA and
one for ECDSA, because the two algorithms are at different stages of
NIST publication. NIST has volunteered to write these two drafts, but
additional co-editors are welcome. (Slides)<br>
&nbsp;&nbsp;<br>
<br>
Service Names as Subject Alt Names - Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The draft has been revised since its
initial version. It no longer is bound as tightly to the DNS SRV
record example. The assumption here is that the user (host) knows the
service name and domain name and determines whether the server to
which it connects is appropriate, based on the server's certificate.
Steve Kent suggests that we need to revisit the security implications
of use of this facility, given the revised definition of the use
model. Stefan suggests that use of name constraints for this extension
may be appropriate. Since the string comparison is against the locally
configured service name, not the DNS SRV string, UTF8 seems to be the
right encoding choice. (Slides)<br>
<br>
<br>
Related Specifications &amp; Liaison Presentations<br>
<br>
Carl Wallace (Orion Security) - LTANS WG status<br>
<x-tab> </x-tab>LTANS is meeting the same day (in the same room) at
this IETF. Carl requests review by PKIX WG members of the evidence
record I-D and an archive protocol I-D from LTANS. Note potential
relationships between SCVP and LTNANS work.&nbsp; (no
slides)</font></div>
</body>
</html>
--======_-1080723712=_ma======--

Date: Sun, 06 Nov 2005 18:30:32 -0500
To: Terry Hayes <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Public key validation and Proof of possession
Sender: [email-masked]

<html>
<body>
RFC 3280 says:<br><br>
&nbsp;&nbsp; To promote interoperability, this profile RECOMMENDS that
policy<br>
&nbsp;&nbsp; information terms consist of only an OID.&nbsp; Where an OID
alone is<br>
&nbsp;&nbsp; insufficient, this profile strongly recommends that use of
qualifiers<br>
&nbsp;&nbsp; be limited to those identified in this section.&nbsp; When
qualifiers are<br>
&nbsp;&nbsp; used with the special policy anyPolicy, they MUST be limited
to the<br>
&nbsp;&nbsp; qualifiers identified in this section.<br><br>
Russ<br><br>
At 04:18 PM 10/27/2005, Terry Hayes wrote:<br>
<blockquote type=cite class=cite cite="">What's wrong with defining a new
policy qualifier?<br>
&nbsp;<br>
id-qt-ietf-pkix-key-validation-performed<br>
id-qt-ietf-pkix-proof-of-posession-performed
(owner-posession-of-key-assured?)<br>
&nbsp;<br>
These would generally be asserted only in the end-entity
certificates.<br>
&nbsp;<br>
Terry Hayes<br><br>
&nbsp;<br>
On 10/27/05, <b>Stefan Santesson</b>
&lt;<a href="mailto:[email-masked]">[email-masked] </a>&gt;
wrote: <br>

<dl><br>

<dd>It is not a proposal.<br>

<dd>I just wanted to add it to the picture.<br><br>

<dd>I'm just generally worried about adding new extensions for every
<br>

<dd>specific certificate policy aspect that can be argued to be useful
to<br>

<dd>have explicitly encoded.<br><br>

<dd>If we go that path, we may need to consider a common framework for
it.<br>

<dd>qcStatement is one, suitable or not.<br><br>
<br>

<dd>Stefan Santesson<br>

<dd>Program Manager, Standards Liaison<br>

<dd>Windows Security<br><br>

</dl></blockquote></body>
</html>

Date: Mon, 07 Nov 2005 10:20:46 +1100
From: Steven Legg <[email-masked]>
To: Tom Yu <[email-masked]>
CC: Peter Sylvester <[email-masked]>, =?ISO-8859-1?Q?Love_H?= =?ISO-8859-1?Q?örnquist_Åstrand?= <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Sender: [email-masked]

Tom,

Tom Yu wrote:
>>>>>>"Peter" = Peter Sylvester <[email-masked]> writes:
> 
> 
> Peter> Steven Legg wrote:
> 
> 
>>>Love, et al,
>>>
>>>Love Hörnquist Åstrand wrote:
>>>
>>>
>>>>Lets take another example:
>>>>
>>>>PA-PK-AS-REQ ::= SEQUENCE {
>>>>signedAuthPack          [0] IMPLICIT OCTET STRING,
>>>>-- Contains a CMS type ContentInfo encoded
>>>>-- according to [RFC3852].
>>>>-- The contentType field of the type ContentInfo
>>>>-- is id-signedData (1.2.840.113549.1.7.2),
>>>>-- and the content field is a SignedData.
>>>>
>>>>With you syntax this should be
>>>>
>>>>signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
>>>>
>>>>Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
>>>>Kerberos datatypes uses DER.
>>>>
>>>>How is that expressed in a formal way ?
>>>
>>>
>>>signedAuthPack IMPLICIT OCTET STRING
> 
> 
> "IMPLICIT" only goes after a tag, so the above should contain something
> like "[0] IMPLICIT"

Quite right. I was focussed on the constraint and didn't notice the tag
had been dropped.

or drop the IMPLICIT completely.  Dropping the
> context-specific tag would cause a change in wire encoding from
> pkinit-29.
> 
> 
>>>(CONTAINING ContentInfo
>>>ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2)
>>>distinguished-encoding(1)})
>>>OPTIONAL
>>>
>>>The OID after the "ENCODED BY" is the OID that identifies DER.
> 
> 
> Except here, we are using a CMS message, which is permitted to be
> encoded in BER, and pkinit requires DER, so you really want something
> like
> 
> PA-PK-AS-REQ ::= SEQUENCE {
>     signedAuthPack [0] IMPLICIT OCTET STRING
>         (CONTAINING ContentInfo ENCODED BY {
>             joint-iso-itu-t asn1 (1) basic-encoding (1)
>         })
> }

I'm not an expert on this but it would seem that as far as pkinit is
concerned, the encoding of a ContentInfo value contained in the
signedAuthPack component of a PA-PK-AS-REQ value is always a DER
encoding. It doesn't matter what encoding rules CMS uses to encode
values of ContentInfo, and the constraint has no effect whatsoever
on encodings of ContentInfo values outside the signedAuthPack component.

> 
> You'll need to normatively reference X.682, because the "CONTAINING"
> constraint isn't in X.680.

Yes.

> 
> 
>>>>Just saying IMPORT and CONTANING and expect the right thing to
>>>>happen when
>>>>given to a compiler seems very naive.
>>>
>>>
>>>There's a better chance that the compiler can do something useful than if
>>>the requirements are expressed informally as a comment.
>>>
>>>Regards,
>>>Steven
>>>
>>>
>>>>Love
>>>>
> 
> 
> What one can expect from the compiler depends on what sort of compiler
> one is using.  The open-source ASN.1 toolkits with acceptable license
> conditions often omit much of the functionality of the full ASN.1
> standard.

And they always will if ASN.1 specifications always pander to the lowest
common denominator. Contents constraints are a nudge in the right direction.

Regards,
Steven

> ---Tom

Date: Sun, 06 Nov 2005 21:08:49 +0100
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography  for InitialAuthentication in Kerberos
Sender: [email-masked]

Peter Sylvester wrote:
> 
> The message was not necessarily to promote AUTOMATIC, but a question
> why there is a different tagging regime involved which is not totally 
> respected
> because OCTET STRINGS are IMPLICIT tagged when the contain other
> syntaxes.

What do you mean here? Which clause of the ASN.1 standard states that 
"OCTET STRINGS are IMPLICIT tagged when the contain other syntaxes".
Also, what does "contain other syntaxes" mean? Do you mean "contain the 
encoding of an ASN.1 value"?
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

Date: Sun, 06 Nov 2005 16:14:17 +0100
From: Peter Sylvester <[email-masked]>
To: Steven Legg <[email-masked]>
CC: [email-masked], Olivier Dubuisson <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010906020804060804020307
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

BTW:

Since SNACC is mentioned. There is one application thta uses SNACC, and in
order to decode soem data encapsulated in an OCTET STRING the author
has changed the syntax to something like

[UNIVERSAL 4] IMPLICIT SEQUENCE {data TheType}

and then changed in the generated code the generation/parsing of the 
constructed
bit by hand. If the syntax would not have the addition OCTET STRING 
encapsulation
such a hack wouldn't be necessary.

Steven Legg wrote:

>
> Olivier Dubuisson wrote:
>
>> The right syntax is:
>> subjectName [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL
>>
>> It would be even better to add an "ENCODED BY oid" after "CONTAINING 
>> Name" with 'oid' being the OID of the binary encoding rules used to 
>> encode 'Name'.
>>
>> But I can already hear some people saying: This is not supported by 
>> Snacc :(
>
>
> Since the constraint does not change the bits on the wire for BER the
> simple retort is: "If your ASN.1 compiler does not support
> CONTAINING constraints then comment them out". The hardship caused to
> users of dumber ASN.1 toolkits is negligible in a case like this.
>
> Regards,
> Steven
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autoritÃ©; 
die Liste mit zurÃ¼ckgerufenen Zertifikaten finden Sie da auch. 

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

eDMC8+IoYv8AAAAAAAA--------------ms010906020804060804020307--

Date: Sun, 06 Nov 2005 16:14:09 +0100
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Olivier Dubuisson <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography  for InitialAuthentication in Kerberos
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040409080102030803000206
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I think we may have a different opinion of what could be maintenance.
Feel free to explain.

Anyway, You can do exactly what AUTOMATIC does with concrete tags.

The message was not necessarily to promote AUTOMATIC, but a question
why there is a different tagging regime involved which is not totally 
respected
because OCTET STRINGS are IMPLICIT tagged when the contain other
syntaxes.

Russ Housley wrote:

>
> I find AUTOMATIC TAGS to be more difficult later down the line when 
> one is doing maintenance. In my opinion, it hides too much.
>
> Russ
>
> At 09:10 AM 11/3/2005, Olivier Dubuisson wrote:
>
>> Tom Gindin wrote:
>>
>>> If it isn't too late to fix this without breaking lots of 
>>> implementations, the ASN.1 in this specification is over-tagged. In 
>>> section 3.2.1, all three of the tags in PA-PK-AS-REQ are 
>>> unnecessary, and the one on signedAuthPack is actually slightly 
>>> harmful. None of the tags in PKAuthenticator do any good either. The 
>>> OCTET STRING wrappings for subjectName and issuerAndSerialNumber are 
>>> not really appropriate, and subjectName doesn't need a tag. Even in 
>>> AuthPack, pkAuthenticator and clientDHNonce don't need tags.
>>> Similarly, in 3.2.3, there is no reason for any of the tags in 
>>> PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo. The tags in ReplyKeyPack 
>>> in 3.2.3.2 also seem unnecessary.
>>
>>
>> The easiest thing would be to put "AUTOMATIC TAGS" in the module 
>> header (instead of "EXPLICIT TAGS") and not bother with tags, for 
>> "AUTOMATIC TAGS" would tag where necessary. But I understand from 
>> another response that the Kerberos team doesn't want to deviate from 
>> their historical choice...
>> -- 
>> Olivier DUBUISSON
>> France Telecom
>> Recherche & Developpement
>> R&D/MAPS/AMS - 22307 Lannion Cedex - France
>> t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/
>>
>>
>
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autoritÃ©; 
die Liste mit zurÃ¼ckgerufenen Zertifikaten finden Sie da auch. 

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

OoIT16EyrUYAAAAAAAA--------------ms040409080102030803000206--

To: Peter Sylvester <[email-masked]>
Cc: Steven Legg <[email-masked]>, =?iso-8859-1?q?Love_Hörnquist_Åstrand?= <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: Tom Yu <[email-masked]>
Date: Sun, 06 Nov 2005 01:01:06 -0500
Lines: 77
Sender: [email-masked]

>>>>> "Peter" = Peter Sylvester <[email-masked]> writes:

Peter> Steven Legg wrote:

>> Love, et al,
>> 
>> Love Hörnquist Åstrand wrote:
>> 
>>> Lets take another example:
>>> 
>>> PA-PK-AS-REQ ::= SEQUENCE {
>>> signedAuthPack          [0] IMPLICIT OCTET STRING,
>>> -- Contains a CMS type ContentInfo encoded
>>> -- according to [RFC3852].
>>> -- The contentType field of the type ContentInfo
>>> -- is id-signedData (1.2.840.113549.1.7.2),
>>> -- and the content field is a SignedData.
>>> 
>>> With you syntax this should be
>>> 
>>> signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
>>> 
>>> Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
>>> Kerberos datatypes uses DER.
>>> 
>>> How is that expressed in a formal way ?
>> 
>> 
>> signedAuthPack IMPLICIT OCTET STRING

"IMPLICIT" only goes after a tag, so the above should contain something
like "[0] IMPLICIT" or drop the IMPLICIT completely.  Dropping the
context-specific tag would cause a change in wire encoding from
pkinit-29.

>> (CONTAINING ContentInfo
>> ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2)
>> distinguished-encoding(1)})
>> OPTIONAL
>> 
>> The OID after the "ENCODED BY" is the OID that identifies DER.

Except here, we are using a CMS message, which is permitted to be
encoded in BER, and pkinit requires DER, so you really want something
like

PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack [0] IMPLICIT OCTET STRING
        (CONTAINING ContentInfo ENCODED BY {
            joint-iso-itu-t asn1 (1) basic-encoding (1)
        })
}

You'll need to normatively reference X.682, because the "CONTAINING"
constraint isn't in X.680.

>>> Just saying IMPORT and CONTANING and expect the right thing to
>>> happen when
>>> given to a compiler seems very naive.
>> 
>> 
>> There's a better chance that the compiler can do something useful than if
>> the requirements are expressed informally as a comment.
>> 
>> Regards,
>> Steven
>> 
>>> 
>>> Love
>>> 

What one can expect from the compiler depends on what sort of compiler
one is using.  The open-source ASN.1 toolkits with acceptable license
conditions often omit much of the functionality of the full ASN.1
standard.

---Tom

Date: Fri, 04 Nov 2005 09:55:48 +1100
From: Steven Legg <[email-masked]>
To: [email-masked]
CC: Olivier Dubuisson <[email-masked]>, Peter Sylvester <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
Sender: [email-masked]

Olivier Dubuisson wrote:
> The right syntax is:
> subjectName   [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL
> 
> It would be even better to add an "ENCODED BY oid" after "CONTAINING 
> Name" with 'oid' being the OID of the binary encoding rules used to 
> encode 'Name'.
> 
> But I can already hear some people saying: This is not supported by 
> Snacc :(

Since the constraint does not change the bits on the wire for BER the
simple retort is: "If your ASN.1 compiler does not support
CONTAINING constraints then comment them out". The hardship caused to
users of dumber ASN.1 toolkits is negligible in a case like this.

Regards,
Steven

Date: Thu, 03 Nov 2005 10:51:51 -0500
To: Olivier Dubuisson <[email-masked]>, Tom Gindin <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I find AUTOMATIC TAGS to be more difficult later down the line when 
one is doing maintenance.  In my opinion, it hides too much.

Russ

At 09:10 AM 11/3/2005, Olivier Dubuisson wrote:

>Tom Gindin wrote:
>>         If it isn't too late to fix this without breaking lots of 
>> implementations, the ASN.1 in this specification is 
>> over-tagged.  In section 3.2.1, all three of the tags in 
>> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack is 
>> actually slightly harmful.  None of the tags in PKAuthenticator do 
>> any good either.  The OCTET STRING wrappings for subjectName and 
>> issuerAndSerialNumber are not really appropriate, and subjectName 
>> doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
>> clientDHNonce don't need tags.
>>         Similarly, in 3.2.3, there is no reason for any of the 
>> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in 
>> ReplyKeyPack in 3.2.3.2 also seem unnecessary.
>
>The easiest thing would be to put "AUTOMATIC TAGS" in the module 
>header (instead of "EXPLICIT TAGS") and not bother with tags, for 
>"AUTOMATIC TAGS" would tag where necessary. But I understand from 
>another response that the Kerberos team doesn't want to deviate from 
>their historical choice...
>--
>Olivier DUBUISSON
>France Telecom
>Recherche & Developpement
>R&D/MAPS/AMS - 22307 Lannion Cedex - France
>t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/
>
>

Date: Thu, 03 Nov 2005 15:51:09 +0100
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development
To: Peter Sylvester <[email-masked]>
CC: Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
Sender: [email-masked]

Peter Sylvester wrote:
 > I think I second Tom Gindin.
 >
 > Itseems strange to me to have pieces of the specification
 > as comments of the asn.1.
 >
 > example:
 >
 >          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
 >                   -- Contains a PKIX type Name encoded according to
 >                   -- [RFC3280].
 >                   -- Identifies the certificate subject by the
 >                   -- distinguished subject name.
 >                   -- REQUIRED when there is a distinguished subject
 >                   -- name present in the certificate.
 >
 >
 > The first two lines are syntactic specification, it was common
 > to have such syntactical restrictions until some years ago.
 > The others don't belong to the syntax at all.
 >
 > The first one can be replaced by
 >
 >        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL
 > CONTAINING Name

The right syntax is:
subjectName   [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL

It would be even better to add an "ENCODED BY oid" after "CONTAINING 
Name" with 'oid' being the OID of the binary encoding rules used to 
encode 'Name'.

But I can already hear some people saying: This is not supported by Snacc :(

 > and an IMPORT that imports Name from an appropiate module.

IMPORT*S*

 > There are lots of exemples of useless tagging iKDCDHKeyInfo or
 > PKAuthenticator All base tags are different, and there is only one
 > optional field.
 > Well, that'a a matter of style as well as the global EXPLICIT default.

Not only, an EXPLICIT tagging takes more bytes because you can encode 
more than one tag per value.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

Date: Thu, 03 Nov 2005 15:10:50 +0100
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development
To: Tom Gindin <[email-masked]>
CC: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for  InitialAuthentication in Kerberos
Sender: [email-masked]

Tom Gindin wrote:
>         If it isn't too late to fix this without breaking lots of 
> implementations, the ASN.1 in this specification is over-tagged.  In 
> section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
> the one on signedAuthPack is actually slightly harmful.  None of the tags 
> in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
> subjectName and issuerAndSerialNumber are not really appropriate, and 
> subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
> clientDHNonce don't need tags.
>         Similarly, in 3.2.3, there is no reason for any of the tags in 
> PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
> 3.2.3.2 also seem unnecessary.

The easiest thing would be to put "AUTOMATIC TAGS" in the module header 
(instead of "EXPLICIT TAGS") and not bother with tags, for "AUTOMATIC 
TAGS" would tag where necessary. But I understand from another response 
that the Kerberos team doesn't want to deviate from their historical 
choice...
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

Date: Thu, 03 Nov 2005 14:11:52 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010506020400030704010003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The current text has some improvements and simplifications, addressing
some points that I have been repeating since years.
but does not address adequately all the issues that had been discussed
after the Paris meeting with Tim Polk, in particular some are
misunderstood.

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

Grp1HBOuBywAAAAAAAA--------------ms010506020400030704010003--

Importance: Normal
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-21.txt
From: [email-masked]
To: [email-masked]
Date: Thu, 3 Nov 2005 12:44:22 +0100
Sender: [email-masked]

Date: Thu, 03 Nov 2005 10:37:49 +0100
From: Peter Sylvester <[email-masked]>
To: Steven Legg <[email-masked]>
CC: =?ISO-8859-1?Q?Love_Hörnquist_Åstrand?= <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050504060708090503010803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I stand corrected (for the syntax). For the rest, I am not sure whether
I could have given an explanation as precisely as Steve. :-)

Peter

Steven Legg wrote:

>
>
> Love, et al,
>
> Love Hörnquist Åstrand wrote:
>
>> Peter Sylvester <[email-masked]> writes:
>>
>>
>>> The first one can be replaced by
>>>
>>>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL 
>>> CONTAINING Name
>>
>
> The correct syntax here is:
>
>          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name) 
> OPTIONAL
>
>>
>>
>> Lets take another example:
>>
>>        PA-PK-AS-REQ ::= SEQUENCE {
>>           signedAuthPack          [0] IMPLICIT OCTET STRING,
>>                    -- Contains a CMS type ContentInfo encoded
>>                    -- according to [RFC3852].
>>                    -- The contentType field of the type ContentInfo
>>                    -- is id-signedData (1.2.840.113549.1.7.2),
>>                    -- and the content field is a SignedData.
>>
>> With you syntax this should be
>>
>>     signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
>>
>> Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
>> Kerberos datatypes uses DER.
>>
>> How is that expressed in a formal way ?
>
>
> signedAuthPack IMPLICIT OCTET STRING
>                   (CONTAINING ContentInfo
>                    ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2) 
> distinguished-encoding(1)})
>                   OPTIONAL
>
> The OID after the "ENCODED BY" is the OID that identifies DER.
>
>>
>> Just saying IMPORT and CONTANING and expect the right thing to happen 
>> when
>> given to a compiler seems very naive.
>
>
> There's a better chance that the compiler can do something useful than if
> the requirements are expressed informally as a comment.
>
> Regards,
> Steven
>
>>
>> Love
>>
>
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. 

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

MKSH3j0/gesAAAAAAAA--------------ms050504060708090503010803--

Date: Thu, 03 Nov 2005 10:37:43 +1100
From: Steven Legg <[email-masked]>
To: =?ISO-8859-1?Q?Love_Hörnquist_Åstrand?= <[email-masked]>
CC: Peter Sylvester <[email-masked]>, Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Sender: [email-masked]

Love, et al,

Love Hörnquist Åstrand wrote:
> Peter Sylvester <[email-masked]> writes:
> 
> 
>>The first one can be replaced by
>>
>>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

The correct syntax here is:

          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name) OPTIONAL

> 
> 
> Lets take another example:
> 
>        PA-PK-AS-REQ ::= SEQUENCE {
>           signedAuthPack          [0] IMPLICIT OCTET STRING,
>                    -- Contains a CMS type ContentInfo encoded
>                    -- according to [RFC3852].
>                    -- The contentType field of the type ContentInfo
>                    -- is id-signedData (1.2.840.113549.1.7.2),
>                    -- and the content field is a SignedData.
> 
> With you syntax this should be
> 
> 	signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
> 
> Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
> Kerberos datatypes uses DER.
> 
> How is that expressed in a formal way ?

signedAuthPack IMPLICIT OCTET STRING
                   (CONTAINING ContentInfo
                    ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2) distinguished-encoding(1)})
                   OPTIONAL

The OID after the "ENCODED BY" is the OID that identifies DER.

> 
> Just saying IMPORT and CONTANING and expect the right thing to happen when
> given to a compiler seems very naive.

There's a better chance that the compiler can do something useful than if
the requirements are expressed informally as a comment.

Regards,
Steven

> Love

To: Peter Sylvester <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Tom Gindin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: =?iso-8859-1?q?Love_Hörnquist_Åstrand?= <[email-masked]>
Date: Wed, 02 Nov 2005 21:00:56 +0100
Sender: [email-masked]

--=-=-

Peter,

> Tagging is a matter of ket's say "taste", in fact, it is a matter of
> implementation
> experience. ASN.1 after many years has come with AUTOMATIC tags
> allowing automatically unambiguous and non-excessive explicit tagging.

The excessive amount of tagging seems like minor nit, its bloaty, sure, its
like rest of the Kerberos protocol.

> Wrapping: Strong boundaries would make sense if you don't have to
> cross them
>
> Interoperability note: Some implementations may not be able to decode
>    wrapped CMS objects encoded with BER but not DER; specifically, they
>    may not be able to decode infinite length encodings. 
>
>
>
> something that seems to be necessary according to the previous citation.
>
> As soon as you have the data structure that you wrap,
> you can also encode them in DER. I doubt that you just have the
> octet string contents only available as blobs.

The CMS implemtetion might use another asn1-package then then Kerberos
implemetation, I think today that this is the common case. You call CMS
package, get back blob, and you have no clue about the encoding it used
used.

Love

--=-=-Content-Type: application/pgp-signature

--=-=-=--

To: Peter Sylvester <[email-masked]>
Cc: Tom Gindin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: =?iso-8859-1?q?Love_Hörnquist_Åstrand?= <[email-masked]>
Date: Wed, 02 Nov 2005 20:53:44 +0100
Sender: [email-masked]

--=-=-

Peter Sylvester <[email-masked]> writes:

> The first one can be replaced by
>
>         subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

Lets take another example:

       PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-signedData (1.2.840.113549.1.7.2),
                   -- and the content field is a SignedData.

With you syntax this should be

	signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo

Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
Kerberos datatypes uses DER.

How is that expressed in a formal way ?

Just saying IMPORT and CONTANING and expect the right thing to happen when
given to a compiler seems very naive.

Love

--=-=-Content-Type: application/pgp-signature

--=-=-=--

From: [email-masked]
To: [email-masked], Sam Hartman <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Date: Wed, 02 Nov 2005 18:20:19 +0000
Sender: [email-masked]

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

Denis - doesnt the idea that the IETF as a whole needs to sign off on ASN.1 Notation in order for their to be any responsibility of any A-D's anywhere to push it seem reasonable to you? Or does PKIX rule the IETF still? 

Todd Glassey

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_0
Content-Type: message/rfc822

From:    [email-masked]
To:    Sam Hartman <[email-masked]>
Cc:    Tom Gindin <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject:    Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Date:    Wed, 2 Nov 2005 17:03:36 +0000
Content-Type: Multipart/mixed;
 boundary="NextPart_Webmail_9m3u9jl4l_1090_1130955619_1"

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_1--

--NextPart_Webmail_9m3u9jl4l_1090_1130955619_0--

Date: Wed, 02 Nov 2005 16:58:33 +0100
From: Peter Sylvester <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: Tom Gindin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080808090809000606010300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Sam,

Just because I find your response strange I'd like to add some reamrks.
Why do you mention PKIX here. Tom didn't mention it at all.
You could as well have mentioned SMIME.
Anyway, not too important.

Saying that kerberos has other rules than PKIX has nothing to
do with the problem. besides that PKIX has no rules and continue
s to use obsolete ASN.1, thus it may be good to use something else,
i.e. to ignore whatever some PKIX authors are proposing. :-)

There are two issues in Tom's message: The tagging with
context tags almost always explicit, and the wrapping.

Tagging is a matter of ket's say "taste", in fact, it is a matter of 
implementation
experience. ASN.1 after many years has come with AUTOMATIC tags
allowing automatically unambiguous and non-excessive explicit tagging.

The actual tagging appeared in the 03 draft in 1997 as far as I see.
The krb-wg first meeting was in Jul 2000 but the text was obviously
discussed before in cat. well, let's see the mail archives of this group.
oops. It is difficult to determine now what has "always" been discussed.

Wrapping: Strong boundaries would make sense if you don't have to
cross them

Interoperability note: Some implementations may not be able to decode
   wrapped CMS objects encoded with BER but not DER; specifically, they
   may not be able to decode infinite length encodings. 

something that seems to be necessary according to the previous citation.

As soon as you have the data structure that you wrap,
you can also encode them in DER. I doubt that you just have the
octet string contents only available as blobs.

I refer to the minutes of San Diego concerning the use of DER/BER
and wrapping. Must have been real fun, this meeting
The argument of the difficulties of parsing BER (in particular
when it is totally unrestricted) seem right to me, or better, that
it is too complex to mandate a BER parser.

There may be good arguments after years to keep the syntax or the bits
on the wire but it has been change just a year ago after 8 years or so.

Have fun
Peter

>
>    Tom>         If it isn't too late to fix this without breaking
>    Tom> lots of implementations, the ASN.1 in this specification is
>    Tom> over-tagged.  In section 3.2.1, all three of the tags in
>    Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
>    Tom> is actually slightly harmful.  None of the tags in
>    Tom> PKAuthenticator do any good either.  The OCTET STRING
>    Tom> wrappings for subjectName and issuerAndSerialNumber are not
>    Tom> really appropriate, and subjectName doesn't need a tag.  Even
>    Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
>    Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
>    Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
>    Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.
>
>The kerberos working group has a rather different philosophy on ASN.1
>than the PKIX community.  We've attempted to draw strong boundaries
>around structures to the extent that we can: kerberos structures use
>our conventions; PKIX structures use yours.
>
>The short answer is that tagging issues have been discussed
>extensively across all our ASN.1 usage.
>
>
>
>  
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autoritÃ©; 
die Liste mit zurÃ¼ckgerufenen Zertifikaten finden Sie da auch. 

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

wrC6e6LdozYAAAAAAAA--------------ms080808090809000606010300--

Importance: Normal
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: [email-masked]
To: Sam Hartman <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 2 Nov 2005 15:29:59 +0100
Sender: [email-masked]

From: [email-masked]
To: Sam Hartman <[email-masked]>, Tom Gindin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Date: Tue, 01 Nov 2005 19:20:32 +0000

Sam what you are looking at is the obvious incompetence in the IETF and ISOC's management to allow for a myriad of incompatible notation schemas... Just another reason why the IETF is a joke.

Todd Glassey
 -------------- Original message ----------------------
From: Sam Hartman <[email-masked]>
> 
> >>>>> "Tom" = Tom Gindin <[email-masked]> writes:
> 
>     Tom>         If it isn't too late to fix this without breaking
>     Tom> lots of implementations, the ASN.1 in this specification is
>     Tom> over-tagged.  In section 3.2.1, all three of the tags in
>     Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
>     Tom> is actually slightly harmful.  None of the tags in
>     Tom> PKAuthenticator do any good either.  The OCTET STRING
>     Tom> wrappings for subjectName and issuerAndSerialNumber are not
>     Tom> really appropriate, and subjectName doesn't need a tag.  Even
>     Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
>     Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
>     Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
>     Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.
> 
> The kerberos working group has a rather different philosophy on ASN.1
> than the PKIX community.  We've attempted to draw strong boundaries
> around structures to the extent that we can: kerberos structures use
> our conventions; PKIX structures use yours.
> 
> The short answer is that tagging issues have been discussed
> extensively across all our ASN.1 usage.
> 

Date: Tue, 01 Nov 2005 19:15:24 +0100
From: Peter Sylvester <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060708060608030909050701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I think I second Tom Gindin.

Itseems strange to me to have pieces of the specification
as comments of the asn.1.

example:

          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
                   -- Identifies the certificate subject by the
                   -- distinguished subject name.
                   -- REQUIRED when there is a distinguished subject
                   -- name present in the certificate.

The first two lines are syntactic specification, it was common
to have such syntactical restrictions until some years ago.
The others don't belong to the syntax at all.

The first one can be replaced by

        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

and an IMPORT that imports Name from an appropiate module. 

I have the feeling that the following sentence doesn't make sense.

   All data structures carried in OCTET
   STRINGs must be encoded according to the rules specified in
   corresponding specifications.

because as far as I remeber the texts, none of the specifications have 
any particular
requirement on the encoding, You can encode everything in XER, can't you?

There are lots of exemples of useless tagging iKDCDHKeyInfo or
PKAuthenticator All base tags are different, and there is only one 
optional field.
Well, that'a a matter of style as well as the global EXPLICIT default.

          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in the PKAuthenticator of the
                   -- request if DH keys are NOT reused,
                   -- 0 otherwise.

To me the comment seems to suggest that

	nonce                   INTEGER (1..4294967295) OPTIONAL 

could be more appropriate. But, the nonce in PKAuthenticator says:

          nonce                   [2] INTEGER (0..4294967295),
                   -- Chosen randomly;  This nonce does not need to
                   -- match with the nonce in the KDC-REQ-BODY.

so it can be 0.

This comment doesn't change anything fundamental of the spec.

Tom Gindin wrote:

>        If it isn't too late to fix this without breaking lots of 
>implementations, the ASN.1 in this specification is over-tagged.  In 
>section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
>the one on signedAuthPack is actually slightly harmful.  None of the tags 
>in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
>subjectName and issuerAndSerialNumber are not really appropriate, and 
>subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
>clientDHNonce don't need tags.
>        Similarly, in 3.2.3, there is no reason for any of the tags in 
>PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
>3.2.3.2 also seem unnecessary.
>
>Tom Gindin
>P.S. - The opinions above are mine, and not necessarily those of my 
>employer.
>
>
>  
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autoritÃ©; 
die Liste mit zurÃ¼ckgerufenen Zertifikaten finden Sie da auch. 

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

1NaE5l46qYAAAAAAAAA--------------ms060708060608030909050701--

To: Tom Gindin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: Sam Hartman <[email-masked]>
Date: Tue, 01 Nov 2005 09:27:12 -0500
Sender: [email-masked]

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

    Tom>         If it isn't too late to fix this without breaking
    Tom> lots of implementations, the ASN.1 in this specification is
    Tom> over-tagged.  In section 3.2.1, all three of the tags in
    Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
    Tom> is actually slightly harmful.  None of the tags in
    Tom> PKAuthenticator do any good either.  The OCTET STRING
    Tom> wrappings for subjectName and issuerAndSerialNumber are not
    Tom> really appropriate, and subjectName doesn't need a tag.  Even
    Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
    Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
    Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
    Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.

The kerberos working group has a rather different philosophy on ASN.1
than the PKIX community.  We've attempted to draw strong boundaries
around structures to the extent that we can: kerberos structures use
our conventions; PKIX structures use yours.

The short answer is that tagging issues have been discussed
extensively across all our ASN.1 usage.

To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: Tom Gindin <[email-masked]>
Date: Tue, 1 Nov 2005 08:36:31 -0500
Sender: [email-masked]

        If it isn't too late to fix this without breaking lots of 
implementations, the ASN.1 in this specification is over-tagged.  In 
section 3.2.1, all three of the tags in PA-PK-AS-REQ are unnecessary, and 
the one on signedAuthPack is actually slightly harmful.  None of the tags 
in PKAuthenticator do any good either.  The OCTET STRING wrappings for 
subjectName and issuerAndSerialNumber are not really appropriate, and 
subjectName doesn't need a tag.  Even in AuthPack, pkAuthenticator and 
clientDHNonce don't need tags.
        Similarly, in 3.2.3, there is no reason for any of the tags in 
PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags in ReplyKeyPack in 
3.2.3.2 also seem unnecessary.

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

Sam Hartman <[email-masked]>
Sent by: [email-masked]
10/28/2005 09:12 AM
 
        To:     [email-masked]
        cc:     [email-masked]
        Subject:        [Jeffrey Hutzelman] LAST CALL - Public Key 
Cryptography for Initial Authentication in Kerberos

Hi.  The Kerberos working group has started a last call on the pkinit
draft.  Pkinit is a mechanism for acquiring kerberos tickets based on
knowledge of a private key.  It also supports and is typically used
with a PKI.

I'd appreciate any review that members of the pkix working group can
provide on this document.

----- Message from Unknown on Unknown -----

solipsist-nation ([unix socket]) by solipsist-nation (Cyrus
v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Sun, 23 Oct 2005 22:07:31
-0400 X-Sieve: CMU Sieve 2.2 Return-Path:
<[email-masked]> Received: from
south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by suchdamage.org (Postfix) with ESMTP id
9BDFA1383E for <[email-masked]>; Sun, 23 Oct 2005 22:07:24
-0400 (EDT) Received: from pacific-carrier-annex.mit.edu
(PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by
south-station-annex.mit.edu (8.12.4/8.9.2) with ESMTP id
j9O27MkZ012927 for <[email-masked]>; Sun, 23 Oct 2005
22:07:22 -0400 (EDT) Received: from mailhost.anl.gov (mailhost.anl.gov
[130.202.113.50]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with
ESMTP id j9O26Emq005270; Sun, 23 Oct 2005 22:06:14 -0400 (EDT)
Received: by mailhost.anl.gov (Postfix) id 18622286; Sun, 23 Oct 2005
21:06:13 -0500 (CDT) Delivered-To: [email-masked]
Received: from mailhost.anl.gov (localhost [127.0.0.1]) by
localhost.ctd.anl.gov (Postfix) with ESMTP id E87EA26D for
<[email-masked]>; Sun, 23 Oct 2005 21:06:12 -0500 (CDT)
Received: by mailhost.anl.gov (Postfix, from userid 10733) id
D6987286; Sun, 23 Oct 2005 21:06:12 -0500 (CDT) X-Original-To:
[email-masked] Delivered-To: [email-masked] Received: from
mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov
(Postfix) with ESMTP id 5D96227F for <[email-masked]>; Sun, 23
Oct 2005 21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov
(mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix)
with ESMTP id 4C9D526D for <[email-masked]>; Sun, 23 Oct 2005
21:06:12 -0500 (CDT) Received: from mailrelay.anl.gov (localhost
[127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id
D63D05F0D5B; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received: from
currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by
mailrelay.anl.gov (Postfix) with SMTP id 7F1595F0D5A for
<[email-masked]>; Sun, 23 Oct 2005 21:06:11 -0500 (CDT) Received:
from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by
currant.srv.cs.cmu.edu id aa18518; 23 Oct 2005 22:06 EDT Received:
from jhutz-dyn0.pc.cs.cmu.edu
(IDENT:U2FsdGVkX1+t+NgCyV0xi/[email-masked]
[128.2.200.136]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu
(8.13.4/8.13.4) with ESMTP id j9O264gX002260 (version=TLSv1/SSLv3
cipheríH-RSA-DES-CBC3-SHA bits8 verify=NO); Sun, 23 Oct 2005
22:06:05 -0400 (EDT) Date: Sun, 23 Oct 2005 22:06:00 -0400 From:
Jeffrey Hutzelman <[email-masked]> To: [email-masked] Cc: Jeffrey
Hutzelman <[email-masked]> Subject: LAST CALL - Public Key Cryptography
for Initial Authentication in Kerberos Message-ID:
<[email-masked]> Originator-Info:
login-token=Mulberry:01ouPFOwxLOq/uLj281WH1qjlV/GYpFz4PWPOg2GM=;
token_authority=[email-masked] X-Mailer: Mulberry/3.1.6
(Linux/x86) Sender: [email-masked] Precedence:
bulk X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version:
SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org
X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0
tests=AWL,BAYES_00 autolearn=ham version=3.0.2
MIME-Version: 1.0

At long last...

As of October 23, 2005, I am beginning a two-week Last Call period
on the following document:

                 Title                           : Public Key Cryptography 
for
                          Initial Authentication in Kerberos
                 Author(s)               : B. Tung, L. Zhu
                 Filename                : 
draft-ietf-cat-kerberos-pk-init-29.txt
                 Pages                           : 36
                 Date                            : 2005-10-21

Comments on this document should be sent to the Kerberos Working Group
mailing list, [email-masked], and will be accepted at least until
11:59pm EST on November 6, 2005.  All issues raised will be entered
into the Request Tracker system at https://rt.psg.com/.

Once the Last Call period has ended, I will make a determination as to
whether there remain any unresolved issue, and whether there is a rough
consensus withing the working group to send this document to the IESG for
publication as a Proposed Standard.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA