Subject: CMS and PKCS7 signedAndEnvelopedData

From: Alicia da Conceicao <[email-masked]>
Date: Sat, 27 Aug 2005 08:13:25 -0400 (EDT)

Greetings:

Does CMS (Cryptographic Message Syntax) support signedAndEnvelopedData
as specified in PKCS7 v 1.5?  I cannot find any references to
signedAndEnvelopedData in RFC-2630.

Has signedAndEnvelopedData been deprecated in favour of placing signedData
within encrypted envelopedData, in order to protect the identity of the
signer?

Thank you in advance.
Alicia.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 28 Aug 2005 18:13:34 -0700

Alicia,

This should be discussed on the S/MIME mailing list not on the PKIX mailing
list.

However here is the answer you are looking for:

signedAndEnvelopedData was dropped from the CMS specification when we moved
from PKCS#7 to CMS on purpose.  The issue is that there are very few cases
where you want to both sign and encrypt a message, but allow the world to
know the party that signed the message.  The correct action now would be to
sign the message and then encrypt it in almost all cases.

jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alicia da Conceicao
> Sent: Saturday, August 27, 2005 5:13 AM
> To: [email-masked]
> Subject: CMS and PKCS7 signedAndEnvelopedData
> 
> 
> Greetings:
> 
> Does CMS (Cryptographic Message Syntax) support 
> signedAndEnvelopedData as specified in PKCS7 v 1.5?  I cannot 
> find any references to signedAndEnvelopedData in RFC-2630.
> 
> Has signedAndEnvelopedData been deprecated in favour of 
> placing signedData within encrypted envelopedData, in order 
> to protect the identity of the signer?
> 
> Thank you in advance.
> Alicia.
> 
> 
>

---

From: Alicia da Conceicao <[email-masked]>
Date: Mon, 29 Aug 2005 07:41:25 -0400 (EDT)

> This should be discussed on the S/MIME mailing list not on the PKIX mailing

Hi Jim:

Thank you for answering my question.  However, I am working on a CMS
application which deals with pure binary data and DER encoded ASN.1.  And
my CMS application nothing to do with S/MIME, e-mail, mime types, or any
type of text headers or fields.  If the PKIX group does not directly
maintain the CMS specification, then please let me know who does.

> sign the message and then encrypt it in almost all cases.

CMS SignedData allows for detached (external) signatures of arbitary
binary data.  One can also detached (external) CMS EnvelopedData with the
decryption details from the actual encrypted data typically placed in the
optional EncryptedContent.

==================================================================
EncryptedContentInfo ::= SEQUENCE {
        contentType ContentType,
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
==================================================================
 
But if I want to encrypt just the data into a file, then put into a
separate file the digital signature of the original data along with
the decryption details?  Without SignedAndEnvelopedData, there does not
appear to be a way to combine the CMS SignedData and CMS EnvelopedData
structures for external signatures with decryption details in a way
that would meet the CMS standard.  Note that detaching the signed and
encrypted data from the CMS structures is very useful when one is
dealing with larged amounts of streamed data.
 
There are many real world cases where you want to both sign and
encrypt a message, and don't care if others can see who signed it.
Especially when one has a centralized trusted organiation, like a CA,
software company, or service provider.  These trusted organiations can
digital signed and distribute CUSTOMIZED secure data that is encrypted
with the customers public keys.  This is useful for provisioning, VoIP,
video on demand, etc.

If anyone has any reasonable work around for SignedAndEnvelopedData that
works with detached encrypted data and still meets the CMS standards,
please let me know.  Otherwise it may be useful to look at ammending
the CMS specification to include SignedAndEnvelopedData.

Thank you in advance.
Alicia.

PS. Note that detached encrypted data is not used in S/MIME so I am
	directing my questions to this mailing list.

---

From: Sam Roberts <[email-masked]>
Date: Mon, 29 Aug 2005 10:58:48 -0400

> maintain the CMS specification, then please let me know who does.

You have some interesting observations, but whether CMS is used within
e-mail applications or not, it is still the S/MIME working group that
maintains and publishes the specs, not the Public Key Infrastructure
(X.509) working group. This is the wrong mailing list.

See:

  http://www.ietf.org/html.charters/smime-charter.html

Cheers,
Sam

-- 
http://www.certicom.com

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Aug 2005 12:56:38 -0400

Alicia:

The SignedAndEnvelopedData was dropped because of a security concern.  An 
attacker can remove the signature, essentially making an EnvelopedData, and 
the recipient has no way to tell that the originator intended to sign and 
encrypt the protected content.

Russ

>within encrypted envelopedData, in order to protect the identity of the

Date: Mon, 29 Aug 2005 12:56:38 -0400
To: Alicia da Conceicao <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CMS and PKCS7 signedAndEnvelopedData
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Alicia:

The SignedAndEnvelopedData was dropped because of a security concern.  An 
attacker can remove the signature, essentially making an EnvelopedData, and 
the recipient has no way to tell that the originator intended to sign and 
encrypt the protected content.

Russ

>within encrypted envelopedData, in order to protect the identity of the

Date: Mon, 29 Aug 2005 10:58:48 -0400
From: Sam Roberts <[email-masked]>
To: Alicia da Conceicao <[email-masked]>
Cc: [email-masked]
Subject: Re: CMS and PKCS7 signedAndEnvelopedData
Mail-Followup-To: Alicia da Conceicao <[email-masked]>, [email-masked]
Sender: [email-masked]

See:

Cheers,
Sam

-- 
http://www.certicom.com

From: Alicia da Conceicao <[email-masked]>
Subject: Re: CMS and PKCS7 signedAndEnvelopedData
To: [email-masked] (Jim Schaad)
Date: Mon, 29 Aug 2005 07:41:25 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Hi Jim:

 

Thank you in advance.
Alicia.

From: "Jim Schaad" <[email-masked]>
To: "'Alicia da Conceicao'" <[email-masked]>, <[email-masked]>
Subject: RE: CMS and PKCS7 signedAndEnvelopedData
Date: Sun, 28 Aug 2005 18:13:34 -0700
Sender: [email-masked]

Alicia,

jim 

> to protect the identity of the signer?

From: Alicia da Conceicao <[email-masked]>
Subject: CMS and PKCS7 signedAndEnvelopedData
To: [email-masked]
Date: Sat, 27 Aug 2005 08:13:25 -0400 (EDT)
Sender: [email-masked]

Greetings:

Thank you in advance.
Alicia.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-crlaia-03.txt 
Date: Fri, 26 Aug 2005 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 
                          Authority Information Access CRL Extension
	Author(s)	: S. Santesson, R. Housley
	Filename	: draft-ietf-pkix-crlaia-03.txt
	Pages		: 8
	Date		: 2005-8-26
	
This document updates RFC 3280 by defining the Authority Information
   Access Certificate Revocation Lists (CRL) extension.  RFC 3280
   defines the Authority Information Access certificate extension using
   the same syntax.  The CRL extension provides a means of discovering
   and retrieving CRL issuer certificates.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-crlaia-03.txt

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: IESG last call changes to the CRL AIA draft
Date: Fri, 26 Aug 2005 13:48:18 +0100
From: "Stefan Santesson" <[email-masked]>
To: "PKIX" <[email-masked]>
Sender: [email-masked]

During IESG last call on the CRL AIA draft, David Cooper submitted some
editorial comments which has been corrected and included in a new draft
03, submitted today.

The changes are:

1) Clarification that a certificate located through this extension, used
to validate signatures on CRLs may not be a CA certificate and thus may
be found in the userCertificate attribute. The old text in section 2
was:

     When the accessLocation is a directoryName, the information is to
     be obtained by the application from whatever directory server is
     locally configured.  The entry for the directoryName contains CA
     certificates in the crossCertificatePair and/or cACertificate
     attributes as specified in [RFC 2587].  The protocol that
     application uses to access the directory (e.g., DAP or LDAP) is a
     local matter.

The new text reads:

     When the accessLocation is a directoryName, the information is to
     be obtained by the application from whatever directory server is
     locally configured.  When one CA public key is used to validate
     signatures on certificates and CRLs, the desired CA certificate is
     stored in the crossCertificatePair and/or cACertificate attributes
     as specified in [RFC 2587].  When different public keys are used to
     validate signatures on certificates and CRLs, the desired
     certificate is stored in the userCertificate attribute as specified
     in [RFC 2587]. Thus, implementations that support the directoryName
     form of accessLocation MUST be prepared to find the needed
     certificate in any of these three attributes.  The protocol that an
     application uses to access the directory (e.g., DAP or LDAP) is a
     local matter.

2) Removing the DER encoded requirement for CMS messages and instead use
reliance on RFC 2797 to specify necessary coding conventions.

3) Aligning the ldap examples so that all now includes the ";binary"
option.

The changes have been concluded and edited in cooperation with Russ,
Sam, Steve and Tim.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

Date: Wed, 24 Aug 2005 14:22:55 -0400
To: Jean-Marc Desperrier <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Can't find info on certificate validity dates
Sender: [email-masked]

My recollection of that discussion is that we will remove all discussion of 
the private key validity period extension altogether in RFC 3280bis.  It 
was pointed out that this is the only extension for which use is actively 
discouraged.  There are many other extensions that have been defined in 
subsequent editions of X.509 for which there is no discussion at all.  It 
was agreed to remove discussion of this one rather than adding discussion 
of all of the new ones.

Russ

At 12:00 PM 8/24/2005, Jean-Marc Desperrier wrote:
>>   There is a certificate extension (private key usage period) for this 
>> purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
>> published in 1999) to discourage its use.
>I think is missing here the fact that this point has been rediscussed in 
>the last IETF meeting, with the suggestion that there might be valid cases 
>of using that extension, and AFAIR the resolution is that we'll remove 
>from RFC3280bis the paragraph discouraging its use.

Date: Wed, 24 Aug 2005 18:30:28 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: Rollover pair sufficient or not?
Sender: [email-masked]

sravan wrote:
> Is there any place where this key rollover & certificate rollover 
> issues are documented?
> I was searching(in vain) for them in the internet for the past one week.
> Please point me to some resources where I can get the following info:
> - certificate rollover process
> - key rollover process
In the standard you should check rfc2510 2.4., and 4.2.
If you need an operational description, you'll need other resources.

> also, during the certificate and/ or key rollover process should the 
> CA maintain 2 sets of CRL dps(one of the old cert & one for new cert) ?
If you do a key rollover, you *must* do the following to simultaneously 
be compatible with existing implementation and do the right thing 
according to the correct implementation of the standard :
- have 2 sets of CRL
- the serial numbers of the certificates issued under the new key must 
not overlap the serial numbers of the certificate issued under the old key
- the crl emitted with the new key must also include the serial numbers 
of the revoked certificat issued under the old key (until the end of the 
validity of the old CA)
- the crl emitted with the old key must also include the serial numbers 
of the revoked certificat issued under the new key (until the old CA is 
no more valid and you can stop creating new one)

Unfortunately, not all software will allow you to do things that way.
If all softwares were doing the right thing according to the standard, 
you could issue only one crl with the new key and including all serial 
numbers. When they are not correct, they need both the crl with the old 
and the new key, but don't care about the serial number issues listed above.

In constrast if you do a cert rollover where you only change the 
validity date, the impact is only to update the cert everywhere.

Date: Wed, 24 Aug 2005 18:00:06 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Can't find info on certificate validity dates
Sender: [email-masked]

Russ Housley wrote:
> Do not expect a relying party to recognize a certificate policy OID 
> and take any special actions to enforce a policy like: "certificate 
> validity period is two years, but it should only be used for signing 
> during the first."
But the certificate policy solution seems quite adequate in that use 
case where we more want to simply inform that the key won't be used 
anymore to sign certificate after the initial period than really want to 
enforce the non-signing rule through that extension.
>   There is a certificate extension (private key usage period) for this 
> purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
> published in 1999) to discourage its use.
I think is missing here the fact that this point has been rediscussed in 
the last IETF meeting, with the suggestion that there might be valid 
cases of using that extension, and AFAIR the resolution is that we'll 
remove from RFC3280bis the paragraph discouraging its use.
>> Would there be problems with using overlapping certificates even when
>> the key doesn't change?
Nope. Many people are doing that. But they usually more extend the 
notAfter date, and keep the same notBefore.
>> I'm thinking a rollover pair in such a setup would be one certificate
>> more than necessary, but then superfluity is not always evil.
That the only way to handle it that situation on long term you will 
after the initial run almost always have two valid certificate at any 
given time.
But when you only change the validity period you don't really need the 
first anymore after you create the new one.

Date: Wed, 24 Aug 2005 19:25:03 +0530
From: sravan <[email-masked]>
To: [email-masked]
Subject: Re: Rollover pair sufficient or not?
Sender: [email-masked]

Hi,
Is there any place where this key rollover & certificate rollover issues 
are documented?
I was searching(in vain) for them in the internet for the past one week.
Please point me to some resources where I can get the following info:
- certificate rollover process
- key rollover process
also, during the certificate and/ or key rollover process should the CA 
maintain 2 sets of CRL dps(one of the old cert & one for new cert) ?

thnx,
sravan

PS: Russ Housley, I am sorry for my previous post. I thought it was 
posted to the group; but it was posted to you.

Russ Housley wrote:

>
> End users that have the new key as a trust anchor will be able to 
> validate certificates signed with the new key in the usual way. 
> However, if they encounter a certificate that is signed with the old 
> key, the key rollover certificate allow them to validate it with a 
> path that leads to the new key trust anchor.
>
> Hope this helps,
> Russ
>
> At 02:09 AM 8/23/2005, Joel Rees wrote:
>
>> I'm reading Planning for PKI and and I've got this ambiguity in my
>> head. The rollover pair is sufficient for building a path back to the
>> original certificate. Therefore, it kind of seems that there might be
>> no need for a normal new CA certificate with just the new key.
>>
>> Or would you want, in addition, a plain CA certificate with just the
>> new key, so that end users who have never seen the old key don't need
>> to think about the old key?
>>
>> Joel Rees <[email-masked]>
>> digitcom, inc. � �式会社デジコ�
>> Kobe, Japan +81-78-672-8800
>> ** <http://www.ddcom.co.jp> **
>>
>>
>>
>>
>>

Date: Wed, 24 Aug 2005 09:47:21 -0400
To: Joel Rees <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Can't find info on certificate validity dates
Sender: [email-masked]

Joel:

Do not expect a relying party to recognize a certificate policy OID and 
take any special actions to enforce a policy like: "certificate validity 
period is two years, but it should only be used for signing during the 
first."  There is a certificate extension (private key usage period) for 
this purpose, and the PKIX WG has decided long ago (before RFC 2459 was 
published in 1999) to discourage its use.

I do not understand your question:
 > Would there be problems with using overlapping certificates even when
 > the key doesn't change?

Did you mean to say: "... even when the key does change?"

You encourage key change over to limit the scope of compromise.  I agree 
with this suggestion.

Russ

At 01:49 AM 8/23/2005, Joel Rees wrote:

>I'm a little late here, but I'd like to check on this --
>
>On 平成 17/08/18, at 2:57, Russ Housley wrote:
>
>>
>>It is best if all of the certificates that will be validated by a
>>given CA certificate have a notAfter data that is earlier (or the
>>same) as the the notAfter date in the CA certificate.
>>
>>If the CA certificate is renewed (the same subject name and the
>>same public key are used with a different validity period), it is
>>possible to avoid this dependence.  However, I believe that most
>>CAs will change their key pair when a new certificate is needed.
>>
>>Russ
>>
>>At 07:58 PM 8/11/2005, Aram Perez wrote:
>>
>>>Hi Folks,
>>>
>>>Is there an RFC that talks about the validity dates on CA
>>>certificates and the validity dates for the certificates it (the CA)
>>>issues? For example, if a "conformant" CA certificate has a notAfter
>>>date of Dec. 31, 2005, should it issue certificates that have a
>>>notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and
>>>couldn't find anything related to my question. The cert path
>>>validation algorithm of 3280 only mentions that the current time be
>>>within the validity dates of the cert being processed.
>
>Would there be problems with using overlapping certificates even when
>the key doesn't change?
>
>I'm inclined to think the key should change anyway, to limit the
>scope of compromise, but would there be anything specifically wrong
>with issuing the initial certificate for, say, two years, with a
>policy that indicates that it will only be used for signing during
>the first year, etc., then issuing a new certificate on the same key
>at the end of each year until whoever makes the decision thinks it
>would be good to roll the key over?
>
>I'm thinking a rollover pair in such a setup would be one certificate
>more than necessary, but then superfluity is not always evil.
>
>My intent with such a plan would be to push period refresh. I'm not
>inclined to trust machines for very long periods of time.
>
>How far out in left field is this idea?
>
>--
>Joel Rees   <[email-masked]>
>digitcom, inc.   � �式会社デジコ�
>Kobe, Japan   +81-78-672-8800
>** <http://www.ddcom.co.jp> **
>
>
>
>
>

Date: Wed, 24 Aug 2005 09:32:06 -0400
To: Joel Rees <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Rollover pair sufficient or not?
Sender: [email-masked]

End users that have the new key as a trust anchor will be able to validate 
certificates signed with the new key in the usual way.  However, if they 
encounter a certificate that is signed with the old key, the key rollover 
certificate allow them to validate it with a path that leads to the new key 
trust anchor.

Hope this helps,
   Russ

At 02:09 AM 8/23/2005, Joel Rees wrote:

>I'm reading Planning for PKI and and I've got this ambiguity in my
>head. The rollover pair is sufficient for building a path back to the
>original certificate. Therefore, it kind of seems that there might be
>no need for a normal new CA certificate with just the new key.
>
>Or would you want, in addition, a plain CA certificate with just the
>new key, so that end users who have never seen the old key don't need
>to think about the old key?
>
>Joel Rees   <[email-masked]>
>digitcom, inc.   � �式会社デジコ�
>Kobe, Japan   +81-78-672-8800
>** <http://www.ddcom.co.jp> **
>
>
>
>
>

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: Protocol Action: 'Internet X.509 Public Key Infrastructure  Operational Protocols: Certificate Store Access via HTTP' to Proposed  Standard 
Date: Tue, 23 Aug 2005 16:23:06 -0400
Sender: [email-masked]

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Operational Protocols: Certificate 
   Store Access via HTTP '
   <draft-ietf-pkix-certstore-http-09.txt> as a Proposed Standard

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-certstore-http-09.txt

Technical Summary

  The protocol conventions described in this document satisfy some of
  the operational requirements of the Internet Public Key Infrastructure
  (PKI).  This document specifies the conventions for using the
  Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to
  obtain certificates and certificate revocation lists (CRLs) from PKI
  repositories.

Working Group Summary

  The PKIX Working Group reached rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

To: [email-masked]
From: Joel Rees <[email-masked]>
Subject: Rollover pair sufficient or not?
Date: Tue, 23 Aug 2005 15:09:17 +0900
Sender: [email-masked]

I'm reading Planning for PKI and and I've got this ambiguity in my  
head. The rollover pair is sufficient for building a path back to the  
original certificate. Therefore, it kind of seems that there might be  
no need for a normal new CA certificate with just the new key.

Or would you want, in addition, a plain CA certificate with just the  
new key, so that end users who have never seen the old key don't need  
to think about the old key?

Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

From: Joel Rees <[email-masked]>
Subject: Re: Can't find info on certificate validity dates
Date: Tue, 23 Aug 2005 14:49:37 +0900
To: [email-masked]
Sender: [email-masked]

I'm a little late here, but I'd like to check on this --

On 平成 17/08/18, at 2:57, Russ Housley wrote:

>
> It is best if all of the certificates that will be validated by a  
> given CA certificate have a notAfter data that is earlier (or the  
> same) as the the notAfter date in the CA certificate.
>
> If the CA certificate is renewed (the same subject name and the  
> same public key are used with a different validity period), it is  
> possible to avoid this dependence.  However, I believe that most  
> CAs will change their key pair when a new certificate is needed.
>
> Russ
>
> At 07:58 PM 8/11/2005, Aram Perez wrote:
>
>> Hi Folks,
>>
>> Is there an RFC that talks about the validity dates on CA
>> certificates and the validity dates for the certificates it (the CA)
>> issues? For example, if a "conformant" CA certificate has a notAfter
>> date of Dec. 31, 2005, should it issue certificates that have a
>> notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and
>> couldn't find anything related to my question. The cert path
>> validation algorithm of 3280 only mentions that the current time be
>> within the validity dates of the cert being processed.

Would there be problems with using overlapping certificates even when  
the key doesn't change?

I'm inclined to think the key should change anyway, to limit the  
scope of compromise, but would there be anything specifically wrong  
with issuing the initial certificate for, say, two years, with a  
policy that indicates that it will only be used for signing during  
the first year, etc., then issuing a new certificate on the same key  
at the end of each year until whoever makes the decision thinks it  
would be good to roll the key over?

I'm thinking a rollover pair in such a setup would be one certificate  
more than necessary, but then superfluity is not always evil.

My intent with such a plan would be to push period refresh. I'm not  
inclined to trust machines for very long periods of time.

How far out in left field is this idea?

--
Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

Date: Mon, 22 Aug 2005 18:57:52 -0400
To: "Stefan Santesson" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Where to store SRV based names
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I went to the DNS tutorial at IETF63. One of the points that was made was 
that the DNS itself did not limit the character set.  It stores an octet 
string.

I suggest that we ask the DNS Directorate for advice.  Perhaps you can work 
with Steve Bellovin, who is a member of the DNS Directorate to carry the 
question forward.  I suspect you will have to help him formulate a concise 
question.

Russ

At 10:55 AM 8/22/2005, Stefan Santesson wrote:

>Originally I suggested IA5String but many voices suggested UTF-8, so
>that is what will go into next draft unless someone has a reason to
>suggest otherwise.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>[mailto:[email-masked]]
> > On Behalf Of David Chadwick
> > Sent: den 22 augusti 2005 12:22
> > To: Tom Gindin
> > Cc: PKIX
> > Subject: Re: Where to store SRV based names
> >
> >
> >
> >
> > Tom Gindin wrote:
> > >         David:
> > >
> > >         We shouldn't use the OID assigned to the subjectAltName
> > extension.
> > >  Instead we should assign a new OID, to be assigned to an
>OTHER-NAME.
> >
> >
> > Hi Tom
> >
> > this is what I intended. Sorry if my last email was not clear enough
> >
> >
> >    We
> > > also can't use PrintableString with Stefan's syntax, because
> > > PrintableString doesn't include underscore and the SRV key normally
> > > contains underscores.  So what is the right string type: IA5String,
> > > VisibleString (a tighter fit than IA5String, but less familiar), or
> > > UTF8String (internationalizable)?
> >
> > It all depends upon what the DNS can store in its SRV RR. IA5string
> > would surely work, but maybe internationalised DNS can store
>UFT8Strings
> > as well, which would be better. We need a DNS expert to advise.
> >
> > >         I agree with the general approach of defining a syntax which
>can
> > > be used either within GeneralName or in a directory attribute.
> >
> > thanks
> >
> > David
> >
> > >
> > >                 Tom Gindin
> > >
> > >
> > >
> > >
> > >
> > >
> > > David Chadwick <[email-masked]>
> > > Sent by: [email-masked]
> > > 08/11/2005 05:25 AM
> > >
> > >         To:     PKIX <[email-masked]>
> > >         cc:
> > >         Subject:        Where to store SRV based names
> > >
> > >
> > >
> > > As a result of my previous message and the various replies to it, it
> > > seems like the arguments against using the
>subjectDirectoryAttributes
> > > extension to store the attribute are
> > >
> > > i) we only have a hammer, so the extension has to be a nail (i.e. we
> > > only support subjectAltNames (and not SDA) so it has to go there),
>and
> > >
> > > ii) since attributes can be anything, we dont want to use them to
>store
> > > this attribute, since attributes are a catch all.
> > >
> > > I dont actually find either arguement technically convincing,
>although I
> > > do find i) pragmatically convincing. (But if we were to extend this
> > > argument PKIX could have been stillborn, because by using this
>argument
> > > we could have said ten years ago that few people were supporting
> > > certificate extensions so lets not use any of them :-)
> > >
> > > However, I do have a solution to offer as follows. Assume that n.n.n
>is
> > > the OID assigned to the subjectAltNames extension. The we define the
> > > following attribute using this OID
> > >
> > > srvName ATTRIBUTE                ::=             {
> > > WITH SYNTAX                              PrintableString (SIZE
>(1..128))
> > > EQUALITY MATCHING RULE                           caseIgnoreMatch
> > > ID                               n.n.n }
> > >
> > > By doing this we ensure:
> > > i) the extension will be carried in the subjectAltNames extension
> > > ii) the syntax and matching rules for the srv string are fully and
> > > compactly defined
> > > iii) If anyone also wanted to store the string in LDAP as an
>attribute
> > > they could do so using the above definition.
> > >
> > > regards
> > >
> > > David
> > >
> > >
> >
> > --
> >
> > *****************************************************************
> > David W. Chadwick, BSc PhD
> > Professor of Information Systems Security
> > The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> > Tel: +44 1227 82 3221
> > Fax +44 1227 762 811
> > Mobile: +44 77 96 44 7184
> > Email: [email-masked]
> > Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> > Research Web site: http://sec.cs.kent.ac.uk
> > Entrust key validation string: MLJ9-DU5T-HV8J
> > PGP Key ID is 0xBC238DE5
> >
> > *****************************************************************

Date: Mon, 22 Aug 2005 14:01:14 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: last call for SIM
Sender: [email-masked]

These is no problem with this dependency.  However, it means that both 
documents must be approved before the RFC Editor will publish the SIM document.

Russ

At 03:39 AM 8/22/2005, Jaeho Yoon wrote:
> > 16. Page 9.
> >
> >   "Before calculating a PEPSI, conforming implementations MUST process
> >   the userPassword with the six step [LDAPBIS STRPREP] string
> >   preparation algorithm as follows":
> >
> > [LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
> > that is an informative reference and use a MUST.
>
>I think it needs to reach an agreement because there remain a lot of 
>further discussion on whether I-D can be referred to use a MUST.
>If the IESG or you give me an appropriate comment, I will reflect it on 
>SIM draft.

Content-class: urn:content-classes:message
Subject: RE: Where to store SRV based names
Date: Mon, 22 Aug 2005 15:55:32 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David Chadwick" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: "PKIX" <[email-masked]>
Sender: [email-masked]

Originally I suggested IA5String but many voices suggested UTF-8, so
that is what will go into next draft unless someone has a reason to
suggest otherwise.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David Chadwick
> Sent: den 22 augusti 2005 12:22
> To: Tom Gindin
> Cc: PKIX
> Subject: Re: Where to store SRV based names
> 
> 
> 
> 
> Tom Gindin wrote:
> >         David:
> >
> >         We shouldn't use the OID assigned to the subjectAltName
> extension.
> >  Instead we should assign a new OID, to be assigned to an
OTHER-NAME.
> 
> 
> Hi Tom
> 
> this is what I intended. Sorry if my last email was not clear enough
> 
> 
>    We
> > also can't use PrintableString with Stefan's syntax, because
> > PrintableString doesn't include underscore and the SRV key normally
> > contains underscores.  So what is the right string type: IA5String,
> > VisibleString (a tighter fit than IA5String, but less familiar), or
> > UTF8String (internationalizable)?
> 
> It all depends upon what the DNS can store in its SRV RR. IA5string
> would surely work, but maybe internationalised DNS can store
UFT8Strings
> as well, which would be better. We need a DNS expert to advise.
> 
> >         I agree with the general approach of defining a syntax which
can
> > be used either within GeneralName or in a directory attribute.
> 
> thanks
> 
> David
> 
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> >
> > David Chadwick <[email-masked]>
> > Sent by: [email-masked]
> > 08/11/2005 05:25 AM
> >
> >         To:     PKIX <[email-masked]>
> >         cc:
> >         Subject:        Where to store SRV based names
> >
> >
> >
> > As a result of my previous message and the various replies to it, it
> > seems like the arguments against using the
subjectDirectoryAttributes
> > extension to store the attribute are
> >
> > i) we only have a hammer, so the extension has to be a nail (i.e. we
> > only support subjectAltNames (and not SDA) so it has to go there),
and
> >
> > ii) since attributes can be anything, we dont want to use them to
store
> > this attribute, since attributes are a catch all.
> >
> > I dont actually find either arguement technically convincing,
although I
> > do find i) pragmatically convincing. (But if we were to extend this
> > argument PKIX could have been stillborn, because by using this
argument
> > we could have said ten years ago that few people were supporting
> > certificate extensions so lets not use any of them :-)
> >
> > However, I do have a solution to offer as follows. Assume that n.n.n
is
> > the OID assigned to the subjectAltNames extension. The we define the
> > following attribute using this OID
> >
> > srvName ATTRIBUTE                ::=             {
> > WITH SYNTAX                              PrintableString (SIZE
(1..128))
> > EQUALITY MATCHING RULE                           caseIgnoreMatch
> > ID                               n.n.n }
> >
> > By doing this we ensure:
> > i) the extension will be carried in the subjectAltNames extension
> > ii) the syntax and matching rules for the srv string are fully and
> > compactly defined
> > iii) If anyone also wanted to store the string in LDAP as an
attribute
> > they could do so using the above definition.
> >
> > regards
> >
> > David
> >
> >
> 
> --
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.ac.uk
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

Date: Mon, 22 Aug 2005 11:22:05 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Tom Gindin <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: Where to store SRV based names
Sender: [email-masked]

Tom Gindin wrote:
>         David:
> 
>         We shouldn't use the OID assigned to the subjectAltName extension. 
>  Instead we should assign a new OID, to be assigned to an OTHER-NAME.

Hi Tom

this is what I intended. Sorry if my last email was not clear enough

   We
> also can't use PrintableString with Stefan's syntax, because 
> PrintableString doesn't include underscore and the SRV key normally 
> contains underscores.  So what is the right string type: IA5String, 
> VisibleString (a tighter fit than IA5String, but less familiar), or 
> UTF8String (internationalizable)?

It all depends upon what the DNS can store in its SRV RR. IA5string 
would surely work, but maybe internationalised DNS can store UFT8Strings 
as well, which would be better. We need a DNS expert to advise.

>         I agree with the general approach of defining a syntax which can 
> be used either within GeneralName or in a directory attribute.

thanks

David

> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> David Chadwick <[email-masked]>
> Sent by: [email-masked]
> 08/11/2005 05:25 AM
>  
>         To:     PKIX <[email-masked]>
>         cc: 
>         Subject:        Where to store SRV based names
> 
> 
> 
> As a result of my previous message and the various replies to it, it 
> seems like the arguments against using the subjectDirectoryAttributes 
> extension to store the attribute are
> 
> i) we only have a hammer, so the extension has to be a nail (i.e. we 
> only support subjectAltNames (and not SDA) so it has to go there), and
> 
> ii) since attributes can be anything, we dont want to use them to store 
> this attribute, since attributes are a catch all.
> 
> I dont actually find either arguement technically convincing, although I 
> do find i) pragmatically convincing. (But if we were to extend this 
> argument PKIX could have been stillborn, because by using this argument 
> we could have said ten years ago that few people were supporting 
> certificate extensions so lets not use any of them :-)
> 
> However, I do have a solution to offer as follows. Assume that n.n.n is 
> the OID assigned to the subjectAltNames extension. The we define the 
> following attribute using this OID
> 
> srvName ATTRIBUTE                ::=             {
> WITH SYNTAX                              PrintableString (SIZE (1..128))
> EQUALITY MATCHING RULE                           caseIgnoreMatch
> ID                               n.n.n }
> 
> By doing this we ensure:
> i) the extension will be carried in the subjectAltNames extension
> ii) the syntax and matching rules for the srv string are fully and 
> compactly defined
> iii) If anyone also wanted to store the string in LDAP as an attribute 
> they could do so using the above definition.
> 
> regards
> 
> David
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

From: "Jaeho Yoon" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: last call for SIM
Date: Mon, 22 Aug 2005 16:39:29 +0900
Sender: [email-masked]

Dear Denis Pinkas,

Thank you for your comments on SIM document.  

The comments you pointed out were very useful to make this document better.

Here are my opinions against your comments. 

At first, as for typos
I will correct them. (5, 7, 8, 9, 11, 14, 15, 17, 18, 19, 22).

and as for the other comments (1, 2, 3, 4, 6, 10, 12, 13, 16, 20, 21)

> 1. Page 2 :
> 
>   "Where the subject is a person, the name that is specified in the
>   subject field of the certificate typically reflects the legal name of
>   the individual and affiliated entities (e.g., their corporate
>   affiliation)".
> 
> "legal name" should not be used.
> 
> Change into:
> 
>   Where the subject is a person, the name that is specified in the
>   subject field of the certificate may reflect the name of
>   the individual and affiliated entities (e.g., their corporate
>   affiliation).

I will accept your opinion.

> 2. Page 2:
> 
>   "Therefore, privacy sensitive identifiers cannot be included in
>   certificates as plaintext".
> 
> There is a case which should be mentioned. Using some QCStatements
> it is possible to include the hash of a picture or of a fingerprint
> in a certificate. This respects privacy and if the picture is sent,
> it can be matched against the hash. ESTI has defined such QCStatements
> in ETSI TS 101 862.
> 
> This is very analogous. In PEPSI a "short" character string is used,
> whereas when a picture or a fingerprint is used the complexity from
> PEPSI is not needed. Users should be informed that there exists an
> alternative to PEPSI.

I can accept your opinion. But for clarification, I'd like to ask you whether a picture or a fingerprint in QCStatements is the equivalent usage to PEPSI.
These seem a bit different types from SIM, I think. 
 
> 3. Page 3 :
> 
>   "Furthermore, the subject can prove to the
>   relying party that they are associated with a valid identification
>   without disclosing the identifier. For example, a person could prove
>   they possessed a valid social security number without disclosing the
>   identifier itself."
> 
> These sentences are unclear. What is the identifier ? It is the social
> security number ?

Text will be changed to :
Furthermore, the subject can prove to the  relying party that they are associated with an identifier without disclosing the identifier. 
For example, a person could prove he/she possessed a specific social security number without actually disclosing the actual social security number itself. 

> 4. Page 3 :
> 
>   "In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
>   sensitive identifier information can be exchanged without disclosing
>   the identifier".
> 
> Later on it can be discovered that this is only useful for a RA - CA 
> protocol but this sentence may let think it is appropriate in a client-server 
> protocol. This should be clarified.

There is nothing to suggest that another specification could not use the EPEPSI structure for communication between items where are not RA/CA.
I don't think this needs to be changed.

> 6. Page 5:
> 
>   "If Alice wishes to prove she has a valid identifier, without
>   disclosing it, then steps 7 and 8 are as follows:"
> 
> It should be mentioned that using this method Bob could "impersonate"
> Alice using the same protocol with another party. This should be addressed
> in the security considerations section. This is fact the most severe
> limitation of PEPSI.

Yes, you are right. And this part was already pointed out by my colleague. It will be added at security consideration part.
 
> 10. Page 7:
> 
>   "One of SHA-1 or SHA-256 MUST be used for ensuring the integrity of PEPSI."
> 
> Since an OID is permitted, any kind of hash function may be used.

We are dealing with standard items which MUST be implemented. Although other algorithms can be used, for interoperability, specific functions needs to be mentioned at "Standard", I think

> 12. Page 7.
> 
>   To meet this requirement, RAs SHOULD encrypt the
>   SIItype, SII, and PEPSI with the CA's public key
> 
> Usually a CA has no public key for encryption but only a public signing key.
> All the features related to the dialog with the CA should be placed in a
> separate section that is NOT mandatory to implement to claim conformance
> with this specification. In particular EPEPSI should be not mandatory to 
> implement.

"Usually a CA has no public key for encryption but only a public signing key." -> CA can have a public key suitable for encryption and it is not the same key as is used for signing certificates. And in that requirement, I intended that the information which should be sent according to circumstances must be sent securely by encryption method.
 
> 13. Page 8.
> 
>   "As described above, the certificate request message MAY contain the
>   PEPSI. [RFC2314] and [RFC2511] are widely used message syntaxes for
>   certification requests".
> 
> This is not possible since it is said that R is generated by the RA.

It will be added that "RA sends the SIM to Alice" in page 4

> 16. Page 9.
> 
>   "Before calculating a PEPSI, conforming implementations MUST process
>   the userPassword with the six step [LDAPBIS STRPREP] string
>   preparation algorithm as follows":
> 
> [LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
> that is an informative reference and use a MUST.

I think it needs to reach an agreement because there remain a lot of further discussion on whether I-D can be referred to use a MUST.
If the IESG or you give me an appropriate comment, I will reflect it on SIM draft.

> 20. Page 10.
> 
>   "A cryptographically secure hash function such as SHA-1 and SHA-256"
> 
> Should we really mention SHA-1 and SHA-256 ?
>
> 21. Page 10.
> 
>   "since SHA-1 requires 2^80 work factor where 160 is the bit-length of the hash value of SHA-1".
> 
> Is the work factor really 2^80 ?

Concerning about SHA-1, SHA-256, please refer to answer of comment 10. 

And the text will be changed to :
The security of a SIM value is created by the hashing of the R, SIItype and SII values. A SIM value depends on two properties of a hash function; the fact that the it cannot be inverted and the fact that collisions (especially with correctly formatted data) are rare. The current attacks by [WANG] are not applicable to SIM values since the end-entity supplying the SII and SIItype values does not supply all of the data being hashed. Some of the SIM value is provided by the RA in the form of R value.

Jaeho Yoon

Date: Wed, 17 Aug 2005 13:57:06 -0400
To: Aram Perez <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Can't find info on certificate validity dates
Sender: [email-masked]

It is best if all of the certificates that will be validated by a given CA 
certificate have a notAfter data that is earlier (or the same) as the the 
notAfter date in the CA certificate.

If the CA certificate is renewed (the same subject name and the same public 
key are used with a different validity period), it is possible to avoid 
this dependence.  However, I believe that most CAs will change their key 
pair when a new certificate is needed.

Russ

At 07:58 PM 8/11/2005, Aram Perez wrote:
>Hi Folks,
>
>Is there an RFC that talks about the validity dates on CA
>certificates and the validity dates for the certificates it (the CA)
>issues? For example, if a "conformant" CA certificate has a notAfter
>date of Dec. 31, 2005, should it issue certificates that have a
>notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and
>couldn't find anything related to my question. The cert path
>validation algorithm of 3280 only mentions that the current time be
>within the validity dates of the cert being processed.
>
>Thanks,
>Aram Perez
>

To: David Chadwick <[email-masked]>
Cc: PKIX <[email-masked]>
Subject: Re: Where to store SRV based names
From: Tom Gindin <[email-masked]>
Date: Tue, 16 Aug 2005 20:30:26 -0400
Sender: [email-masked]

        David:

        We shouldn't use the OID assigned to the subjectAltName extension. 
 Instead we should assign a new OID, to be assigned to an OTHER-NAME.  We 
also can't use PrintableString with Stefan's syntax, because 
PrintableString doesn't include underscore and the SRV key normally 
contains underscores.  So what is the right string type: IA5String, 
VisibleString (a tighter fit than IA5String, but less familiar), or 
UTF8String (internationalizable)?
        I agree with the general approach of defining a syntax which can 
be used either within GeneralName or in a directory attribute.

                Tom Gindin

David Chadwick <[email-masked]>
Sent by: [email-masked]
08/11/2005 05:25 AM
 
        To:     PKIX <[email-masked]>
        cc: 
        Subject:        Where to store SRV based names

As a result of my previous message and the various replies to it, it 
seems like the arguments against using the subjectDirectoryAttributes 
extension to store the attribute are

i) we only have a hammer, so the extension has to be a nail (i.e. we 
only support subjectAltNames (and not SDA) so it has to go there), and

ii) since attributes can be anything, we dont want to use them to store 
this attribute, since attributes are a catch all.

I dont actually find either arguement technically convincing, although I 
do find i) pragmatically convincing. (But if we were to extend this 
argument PKIX could have been stillborn, because by using this argument 
we could have said ten years ago that few people were supporting 
certificate extensions so lets not use any of them :-)

However, I do have a solution to offer as follows. Assume that n.n.n is 
the OID assigned to the subjectAltNames extension. The we define the 
following attribute using this OID

srvName ATTRIBUTE                ::=             {
WITH SYNTAX                              PrintableString (SIZE (1..128))
EQUALITY MATCHING RULE                           caseIgnoreMatch
ID                               n.n.n }

By doing this we ensure:
i) the extension will be carried in the subjectAltNames extension
ii) the syntax and matching rules for the srv string are fully and 
compactly defined
iii) If anyone also wanted to store the string in LDAP as an attribute 
they could do so using the above definition.

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

From: [email-masked]
To: [email-masked]
Subject: WG: Can't find info on certificate validity dates
Date: Tue, 16 Aug 2005 09:28:59 +0200
Sender: [email-masked]

-----Urspr�ngliche Nachricht-----
Von: Beckmann, Thomas 
Gesendet: Freitag, 12. August 2005 10:17
An: 'Aram Perez'
Betreff: AW: Can't find info on certificate validity dates

Aram,

it's a matter of policy. In gerneral a CA is not prohibited to issue
certificates with a notAfter entry later than the notAfter entry in the CA
certificate.
In the context of the german signature act this is done almost ervery time
because the root is only valid one year and enduser certificates can be
valid up to five years. The idea behind is to have a validation mechanism
different from them PEM and PKIX one. A signature is not checked valid a the
actual time at the time of signature creation. I. e. a certificate should
have been valid at the time of signature creation and can be invalid now but
the signature is still valid.

I hope this helps

Regards

Thomas Beckmann

> -----Urspr�ngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]]Im Auftrag von Aram Perez
> Gesendet: Freitag, 12. August 2005 01:59
> An: [email-masked]
> Betreff: Can't find info on certificate validity dates
> 
> 
> 
> Hi Folks,
> 
> Is there an RFC that talks about the validity dates on CA  
> certificates and the validity dates for the certificates it (the CA)  
> issues? For example, if a "conformant" CA certificate has a notAfter  
> date of Dec. 31, 2005, should it issue certificates that have a  
> notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
> couldn't find anything related to my question. The cert path  
> validation algorithm of 3280 only mentions that the current time be  
> within the validity dates of the cert being processed.
> 
> Thanks,
> Aram Perez
> 
> 

Date: Mon, 15 Aug 2005 18:45:20 -0700
From: Julien Pierre <[email-masked]>
Subject: Re: Can't find info on certificate validity dates
To: "Kazin, Joel" <[email-masked]>
Cc: Aram Perez <[email-masked]>, [email-masked]
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Kazin, Joel wrote:

> My recollection is that RFC 3280 is silent on the issue.  The 
> Microsoft 2003 CA will not sign certificates that have a notAfter date 
> that is greater than its own signing certificate.

If there is no override for this, that sounds like an unfortunate 
restriction. The CA can always choose to renew its own certificate at a 
later date, which would then allow the EE cert to be validated until its 
expiration date. Perhaps it was done this way because the clients don't 
have an automatic way to update the renewed CA cert when/if it is made 
available .

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

--------------ms050800070009030100050908--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-09.txt 
Date: Mon, 15 Aug 2005 15:50:01 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 
                          Operational Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-09.txt
	Pages		: 0
	Date		: 2005-8-15
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI).
This document specifies the conventions for using the Hypertext Transfer
Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and
certificate revocation lists (CRLs) from PKI repositories.  Additional
mechanisms addressing PKIX operational requirements are specified in separate
documents.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certstore-http-09.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-20.txt 
Date: Fri, 12 Aug 2005 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-20.txt
	Pages		: 77
	Date		: 2005-8-12
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-20.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 12 Aug 2005 10:34:18 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: Can't find info on certificate validity dates
To: [email-masked]
Organization: StrongAuth, Inc.
Sender: [email-masked]

On the other hand, I am familiar with another product that provides the
flexibility to issue certificates past its own expiration date.

It is a useful operational practice in a situation where the "Root CA"
certificate of a private company is issued by a public CA and is of a
short duration (1 year), and the PKI operations team would prefer not
to reissue their internal subordinate CA certificates every year, but
just renew the "Root CA" certificate every year and publish it at their
well-known locations so cert-chain validation can continue as usual.
This does help in optimizing some operational procedures when the
key-pair for the "Root CA" does not change.

Arshad Noor
StrongAuth, Inc.

Kazin, Joel wrote:
> My recollection is that RFC 3280 is silent on the issue.  The Microsoft 
> 2003 CA will not sign certificates that have a notAfter date that is 
> greater than its own signing certificate.
> 
> At 06:58 PM 8/11/2005 -0500, Aram Perez wrote:
> 
>> Hi Folks,
>>
>> Is there an RFC that talks about the validity dates on CA 
>> certificates and the validity dates for the certificates it (the CA) 
>> issues? For example, if a "conformant" CA certificate has a notAfter 
>> date of Dec. 31, 2005, should it issue certificates that have a 
>> notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and 
>> couldn't find anything related to my question. The cert path 
>> validation algorithm of 3280 only mentions that the current time be 
>> within the validity dates of the cert being processed.
>>
>> Thanks,
>> Aram Perez 
> 
> 
> Joel S. Kazin CPA, CISA, CISSP, CISM
> Senior Consultant
> Atos Origin
> 40 Old Sleepy Hollow Road
> Pleasantville, New York 10570-3802
> USA
> Phone  +1 914-769-8780
> Mobile  +1 914-564-1484
> email    [email-masked]
> www.atosorigin.com
> <http://www.atosorigin.com/>
> 

Date: Fri, 12 Aug 2005 11:46:05 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: PKIX meeting minutes, final
Cc: [email-masked]
Sender: [email-masked]

PKIX WG Meeting 8/2/05

Edited by Steve Kent

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

The PKIX WG met once during the 63nd IETF. A total of approximately 
53 individuals participated in the meeting.

Document status - Tim Polk (NIST)

	Two new RFCs (PK Algorithms and Permanent Identifier) have 
been issued since the last meeting. Four additional documents have 
been approved by the IESG and are in the RFC editor's queue 
(Certificate path building, warranty extension, 2510bis and 2511bis). 
Three documents are being reviewed by the ADs (AC policies, CertStire 
HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
SIM will be initiated after this IETF meeting. More detailed 
discussions of 3280bis and SCVP will follow. (see slides)

PKIX WG Document Presentations

SRV RR otherName - Stefan Santesson (Microsoft)
	This individual submission is being adopted by PKIX. The 
proposal specifies a way to embed a service name in a certificate, 
employing the syntax used to identify a service in DNS SRV records. 
The intent is to securely bind the DNS-specified service to a named 
entity, using the otherName type of GeneralName to carry the 
specified SRV RR query string. Denis noted that this proposal is a 
somewhat odd use of the subject alt name, in that the string is not 
the name of the certificate subject, but the name of a service 
provided by this subject. Instead he proposed use of the subject 
directory attributes extension. Others objected to this specific way 
of binding service authorization info to a certificate, vs. other 
approaches, e.g., EKU, or other subject alt name forms. There was 
general agreement that the proposal needs to be carefully vetted by 
DNS experts. (see slides)

Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
	IPR issues have been resolved since the last IETF meeting. 
Russ Housely said that CoreStreet indicated that compliant SCVP 
implementations could be developed that would not infringe their 
patents. However, Russ also reminded attendees that ultimately each 
vendor needs to evaluate the formal, legal statements from 
CoreStreet. The base specification has not changed significantly 
since the -18 draft. The draft meets most of the requirements 
specified in RFC 3379, but return of (relayed) SCVP responses was not 
included. This will be fixed in the next draft. Also, the conformance 
requirements seem to impose undue burdens on all clients, contrary to 
the goal of supporting thin clients. Remaining open issues will be 
discussed on the list, e.g., syntax details. (see slides)

SCVP Open Issues - Denis Pinkas (Bull)
	Denis emphasizes the need for thin clients, e.g., on cell 
phones, to be supported. Denis suggested that several OPTIONAL fields 
should be omitted to facilitate thin client support. However, because 
these are optional, it appears that the document can be worded to 
ensure that they impose no burden on a client that does not wish to 
invoke them. Denis would like to see a facility to allow per-trust 
anchor validation parameters, obviously not for thin clients, since 
only a sophisticated client would be able to take advantage of this 
facility. Denis also would like to represent both the validation 
policy and validation algorithm into a single OID. It was agreed that 
the URI pointer to a policy will be deleted. Is also was agreed that 
the terms "validation policy" and "validation algorithm" need to be 
better defined in the document. (see slides)

3280bis - Tim Polk (NIST)
	A new draft has been submitted with relatively minor 
enhancements. Several open issues remain to be resolved. In 
particular, questions involving name ambiguity have been raised, 
particularly as they impact CRL validation. We may deal with this 
issue by adding text in the security considerations section that 
discusses this issue. The text has been changed to clarify what 
conforming CAs MUST do in issuing a certificate, vs. what conforming 
RPs MUST do re certificate path processing. The path validation 
algorithm notes that it accepts paths that are X.509 compliant, but 
not PKIX compliant, in support of interoperability. Peter Sylvester 
asked whether there would be support to help him write a defect 
report against x.509 concerning the change of the name of the 
non-repudiation bit, since this change breaks applications that are 
based on standard ASN.1 compiler outputs (and it changes the XER 
encoding on the wire). (see slides)

3280bis Open Issues - Denis Pinkas (Bull)
	Denis reviewed seven topics that he considers open issues. He 
suggests that text on TA key update should be explicitly covered 
here, not just a reference to RFC 2510. He also suggests that we find 
a better compromise with the latest X.509 technical corrigendum, with 
respect to key usage. Denis reviewed the name ambiguity debate that 
has taken place on the list. He suggested that the private key usage 
extension not be deprecated universally, but rather be allowed in 
certain contexts, e.g., time stamp crypto modules. He proposed to 
soften the prohibition against private key usage or to delete annex 
D.1. (and thus annex D) which is the only section that
addresses this topic. Denis asked for a simplified revocation status 
checking algorithm description, that addresses only the PKIX-mandated 
certificate extensions. He also suggests clarification of the text 
that says what CRLs are "available" in the local cache. Finally, 
Denis discussed several subtle issues associated with indirect CRLs. 
At the microphone a series of individuals responded to Denis's 
suggestions, most disagreed with one of more of his points. (see 
slides)

Related Specifications & Liaison Presentations

CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
of ETSI TC ESI)
	This document is based on RFC 3126 and is aligned with a 
re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
distinguish it from the XML-based version spec. Denis said that the 
document now presents the basic electronic signature formats in the 
main body of the document while placing features to achieve the 
maintenance of long term signatures in informative annexes, thus the 
informative annexes may equally be interesting. (see slides)

XKMS - Stephen Farrell (on behalf of W3C)
	This presentation noted that the XKMS specification in W3C 
was completed and multiple interoperable implementations have been 
tested. Interested PKIX members are encouraged to visit the W3C web 
site and review the spec. (no slides)

From: "Kazin, Joel" <[email-masked]>
To: Aram Perez <[email-masked]>, [email-masked]
Subject: Re: Can't find info on certificate validity dates
Date: Fri, 12 Aug 2005 07:59:26 -0500
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C59F3D.6F564B78
Content-Type: text/plain;
	charset="iso-8859-1"

My recollection is that RFC 3280 is silent on the issue.  The Microsoft 2003
CA will not sign certificates that have a notAfter date that is greater than
its own signing certificate.

At 06:58 PM 8/11/2005 -0500, Aram Perez wrote:

Hi Folks, 

Is there an RFC that talks about the validity dates on CA  
certificates and the validity dates for the certificates it (the CA)  
issues? For example, if a "conformant" CA certificate has a notAfter  
date of Dec. 31, 2005, should it issue certificates that have a  
notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
couldn't find anything related to my question. The cert path  
validation algorithm of 3280 only mentions that the current time be  
within the validity dates of the cert being processed. 

Thanks, 
Aram Perez 

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/> 

------_=_NextPart_001_01C59F3D.6F564B78
Content-Type: text/html;
	charset="iso-8859-1"

<html>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
My recollection is that RFC 3280 is silent on the issue.&nbsp; The
Microsoft 2003 CA will not sign certificates that have a notAfter date
that is greater than its own signing certificate.<br><br>
At 06:58 PM 8/11/2005 -0500, Aram Perez wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Hi Folks,</font>
<br><br>
<font size=2>Is there an RFC that talks about the validity dates on CA&nbsp; </font><br>
<font size=2>certificates and the validity dates for the certificates it (the CA)&nbsp; </font><br>
<font size=2>issues? For example, if a &quot;conformant&quot; CA certificate has a notAfter&nbsp; </font><br>
<font size=2>date of Dec. 31, 2005, should it issue certificates that have a&nbsp; </font><br>
<font size=2>notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and&nbsp; </font><br>
<font size=2>couldn't find anything related to my question. The cert path&nbsp; </font><br>
<font size=2>validation algorithm of 3280 only mentions that the current time be&nbsp; </font><br>
<font size=2>within the validity dates of the cert being processed.</font> <br><br>
<font size=2>Thanks,</font> <br>
<font size=2>Aram Perez</font> </blockquote>
<x-sigsep><p></x-sigsep>
<br>
Joel S. Kazin CPA, CISA, CISSP, CISM<br>
Senior Consultant<br>
Atos Origin<br>
40 Old Sleepy Hollow Road<br>
Pleasantville, New York 10570-3802<br>
USA<br>
Phone&nbsp; +1 914-769-8780<br>
Mobile&nbsp; +1 914-564-1484<br>
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> [email-masked]<br>
<a href="http://www.atosorigin.com/" eudora="autourl">www.atosorigin.com<br>
</a></html>

------_=_NextPart_001_01C59F3D.6F564B78--

Date: Fri, 12 Aug 2005 11:52:31 +0200
From: Denis Pinkas <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: last call for SIM
Sender: [email-masked]

Steve,

Herafter are my comments for the WG last call.

1. Page 2 :

   "Where the subject is a person, the name that is specified in the
   subject field of the certificate typically reflects the legal name of
   the individual and affiliated entities (e.g., their corporate
   affiliation)".

"legal name" should not be used.

Change into:

   Where the subject is a person, the name that is specified in the
   subject field of the certificate may reflect the name of
   the individual and affiliated entities (e.g., their corporate
   affiliation).

2. Page 2:

   "Therefore, privacy sensitive identifiers cannot be included in
   certificates as plaintext".

There is a case which should be mentioned. Using some QCStatements
it is possible to include the hash of a picture or of a fingerprint
in a certificate. This respects privacy and if the picture is sent,
it can be matched against the hash. ESTI has defined such QCStatements
in ETSI TS 101 862.

This is very analogous. In PEPSI a "short" character string is used,
whereas when a picture or a fingerprint is used the complexity from
PEPSI is not needed. Users should be informed that there exists an
alternative to PEPSI.

3. Page 3 :

   "Furthermore, the subject can prove to the
   relying party that they are associated with a valid identification
   without disclosing the identifier. For example, a person could prove
   they possessed a valid social security number without disclosing the
   identifier itself."

These sentences are unclear. What is the identifier ? It is the social
security number ?

4. Page 3 :

   "In addition, this document defines an Encrypted PEPSI(EPEPSI) so that
   sensitive identifier information can be exchanged without disclosing
   the identifier".

Later on it can be discovered that this is only useful for a RA - CA 
protocol
but this sentence may let think it is appropriate in a client-server 
protocol.
This should be clarified.

5. Page 4. Typo :

     - The CA can treat the PEPSI as an additional name form in the
       "subjectAltName" extesnion with no special processing; and
                        ^^^^^^^^^

6. Page 5:

   "If Alice wishes to prove she has a valid identifier, without
   disclosing it, then steps 7 and 8 are as follows:"

It should be mentioned that using this method Bob could "impersonate"
Alice using the same protocol with another party. This should be addressed
in the security considerations section. This is fact the most severe
limitation of PEPSI.

7. Page 5. Typo:

       H()        Cryptographically secure hash algorithm.
                  SHA-1[FIPS 180-1] or more secure hash function is
                  specification required.
                  ^^^^^^^^^^^^^
The above sentence is not English.

8. Page 6. Typo:

   difficult to guess and long enough to protect against bute force
                                                         brute

9. Page 7. Typo:

   A The RA generates a random number, R. A new R MUST be generated for
   ^^^^^

10. Page 7:

   "One of SHA-1 or SHA-256
   MUST be used for ensuring the integrity of PEPSI."

Since an OID is permitted, any kind of hash function may be used.

11. Page 7. Typo:

   "it may be required where the CA itself verifies SII before issuing
                       ^^^^^
   the certificate"

12. Page 7.

   To meet this requirement, RAs SHOULD encrypt the
   SIItype, SII, and PEPSI with the CA's public key

Usually a CA has no public key for encryption but only a public signing key.
All the features related to the dialog with the CA should be placed in a
separate section that is NOT mandatory to implement to claim conformance
with this specification. In particular EPEPSI should be not mandatory to 
implement.

13. Page 8.

   "As described above, the certificate request message MAY contain the
   PEPSI. [RFC2314] and [RFC2511] are widely used message syntaxes for
   certification requests".

This is not possible since it is said that R is generated by the RA.

14. Page 8. Typo. The following sentence has no end.

   "The PEPSI SHOULD be included in the attribute field of ????"

15. Page 8. Typo.

   "A CA issue certificate containing the SIM as a form of otherName from
         ^^^^^ ^^^^^^^^^^^

16. Page 9.

   "Before calculating a PEPSI, conforming implementations MUST process
   the userPassword with the six step [LDAPBIS STRPREP] string
   preparation algorithm as follows":

[LDAPBIS STRPREP] is only an I-D it is not possible to refer to an I-D
that is an informative reference and use a MUST.

17. Page 9. Typo.

      * In step 2, Map, the mapping shall include procedssing of
                                                  ^^^^^^^^^^^

18. Page 10. Typos.

   Threfore, a certificate user transmit simply the password, P, and the
   ^^^^^^^^^                    ^^^^^^^^

19. Page 10. Typo.

   For the last speical use case that a certificate user want to
                ^^^^^^^
   disclose his SII, the only information sent by a ceritificate user is
                                                    ^^^^^^^^^^^^

20. Page 10.

   "A cryptographically secure hash function such as SHA-1 and SHA-256"

Should we really mention SHA-1 and SHA-256 ?

21. Page 10.

   "since SHA-1 requires
   2^80 work factor where 160 is the bit-length of the hash value of
   SHA-1".

Is the work factor really 2^80 ?

22. Page 12. typo.

   illumination. Also, thanks for Russell Housely, Stephen Kent for
                                          ^^^^^^^
Denis

> As per discussions at the IETF meetings last week, I am initiating WG 
> last call on this document:
>
> Internet X.509 Public Key Infrastructure Subject Identification Method 
> (SIM) <draft-ietf-pkix-sim-05.txt>
>
> Although we received a few suggestions for changes, these can be 
> folded in during last call, rather than  waiting for a 06 draft.
>
> The last call will be for 2 weeks.  I will be away on vacation when it 
> ends.  Tim has recused himself from this last call since he is a 
> co-author. So, when I return from vacation and plow through all the 
> e-mail, I'll get back to the list on this topic, after labor day (Sept 
> 6).
>
> Steve
>

Date: Fri, 12 Aug 2005 10:35:08 +0200
From: Denis Pinkas <[email-masked]>
To: S-MIME / IETF <[email-masked]>
CC: pkix <[email-masked]>
Subject: CAdES: <draft-pinkas-smime-cades-01.txt>
Sender: [email-masked]

The I-D for CMS Advanced Electronic Signatures (CAdES) has been updated
to correct a few typos and ASN.1 errors in the ASN.1 modules.

It is now available at:

http://www.ietf.org/internet-drafts/draft-pinkas-smime-cades-01.txt

Denis

To: [email-masked]
From: Aram Perez <[email-masked]>
Subject: Can't find info on certificate validity dates
Date: Thu, 11 Aug 2005 16:58:57 -0700
Sender: [email-masked]

Hi Folks,

Is there an RFC that talks about the validity dates on CA  
certificates and the validity dates for the certificates it (the CA)  
issues? For example, if a "conformant" CA certificate has a notAfter  
date of Dec. 31, 2005, should it issue certificates that have a  
notAfter date of Jul 31, 2008? I search RFCs 3280 and 3647 and  
couldn't find anything related to my question. The cert path  
validation algorithm of 3280 only mentions that the current time be  
within the validity dates of the cert being processed.

Thanks,
Aram Perez

Date: Thu, 11 Aug 2005 10:25:00 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: PKIX <[email-masked]>
Subject: Where to store SRV based names
Sender: [email-masked]

As a result of my previous message and the various replies to it, it 
seems like the arguments against using the subjectDirectoryAttributes 
extension to store the attribute are

i) we only have a hammer, so the extension has to be a nail (i.e. we 
only support subjectAltNames (and not SDA) so it has to go there), and

ii) since attributes can be anything, we dont want to use them to store 
this attribute, since attributes are a catch all.

I dont actually find either arguement technically convincing, although I 
do find i) pragmatically convincing. (But if we were to extend this 
argument PKIX could have been stillborn, because by using this argument 
we could have said ten years ago that few people were supporting 
certificate extensions so lets not use any of them :-)

However, I do have a solution to offer as follows. Assume that n.n.n is 
the OID assigned to the subjectAltNames extension. The we define the 
following attribute using this OID

srvName ATTRIBUTE	::=	{
WITH SYNTAX		PrintableString (SIZE (1..128))
EQUALITY MATCHING RULE		caseIgnoreMatch
ID		n.n.n }

By doing this we ensure:
i) the extension will be carried in the subjectAltNames extension
ii) the syntax and matching rules for the srv string are fully and 
compactly defined
iii) If anyone also wanted to store the string in LDAP as an attribute 
they could do so using the above definition.

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, =?iso-8859-1?Q?Philipp_G=FChring?= <[email-masked]>, "Joel Rees" <[email-masked]>
Subject: New CSR schemes - Requirements
Date: Tue, 9 Aug 2005 23:33:18 +0200
Sender: [email-masked]

Gentlemen,
Since you have both expressed interest in revised CSR schemes,
you may want to look at a recent counterpart for OTP tokens:

http://www.rsasecurity.com/rsalabs/node.asp?id=2817

Compared to PKCS #10 and CRMF, CT-KIP is:
1. XML based
2. Multi pass

That is, revising existing RFCs is not likely to be a good idea since
on-line certification needs multi-pass protocols in order to support
users with limited, or no knowledge of PKI.  Certificate renewal
also requires mult-pass including an atomic replacement operation.

A difference with on-line certification schemes compared to for example
the creation of web-server certificates is that in the former case the CA
is usually the originator of all vital information including key length, subject
DN etc.  This is principally about the opposite of PKCS #10 and CRMF.

So IMHO a new CSR scheme should [at least] allow the CA to define
- key length and type
- PIN/passphrase policy
- key export policy
- All but the public key of the EE certificate(s) to be generated

As well as optionally requiring HW key container PoP & ID.

The goal must be to eliminate as much as possible, any requirements on
the user regarding answering questions that they would never have to
bother with if they got a token distributed in a physical form, while still
providing for a secure process.

Using XML it would not be a PKIX work item.  PKIX is also said to
be shutting down so in case you are interested in such a task we must
find another home for it.

Comments?

Anders Rundgren

Content-class: urn:content-classes:message
Subject: RE: draft minutes for comment
Date: Tue, 9 Aug 2005 14:22:14 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Steve,

I think the SRV RR text is not entirely correct. The proposal is not to
include a pointer to a SRV record. The proposal is to create a name form
that holds a service name and the domain of that service in a way that
matches the content of a dns SRV resource record (not points to it).

This might be a gradual difference but it is important one since the
name in the cert is not intended to be used to construct a dns query,
only to validate a servers authorization to provide a service.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 8 augusti 2005 22:16
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: Re: draft minutes for comment
> 
> 
> Denis,
> 
> >...
> >  >SRV RR otherName - Stefan Santesson (Microsoft)
> >>	An individual submission, now being adopted by PKIX. The
> >>proposal specifies a way to embed a pointer to a DNS SRV record in a
> >>certificate, to securely bind the DNS record to a named entity,
using
> >>the otherName type of GeneralName to carry the specific SRV RR query
> >>string. Denis noted that this proposal is a somewhat odd use of the
> >>subject alt name, in that the string is not the name of the
> >>certificate subject, but the name of a service provided by this
> >>subject.
> >
> >Add:
> >
> >"Denis proposed to use the subject directory attributes extension"
> >which is well suited to carry this kind of extension..
> 
> I'll add the first line.
> 
> >...
> >
> >Russ said a few words about the patent issue. I would not dare to say
it,
> >but it would be useful for the WG to know what was said in the room.
> 
> I added ytext re Russ's comments on the IPR issue.
> 
> >...
> >SCVP - Open Issues - Denis Pinkas (Bull)
> >
> >>	Denis emphasizes the need for thin clients, e.g., on cell
> >>phones, to be supported. Denis suggested that several OPTIONAL
fields
> >>should be omitted to facilitate thin client support. However,
because
> >>these are optional, it appears that the document can be worded to
> >>ensure that they impose no burden on a client that does not wish to
> >>invoke them. Denis would like to see a facility to allow per-trust
> >>anchor validation parameters, obviously not for thin clients, since
> >>only a sophisticated client would be able to take advantage of this
> >>facility. Denis also would like to represent both the validation
> >  >policy and validation algorithm into a single OID,
> >
> >Please delete: "although this seems to yield a minor space/complexity
> saving",
> >since the topic is much more important than space saving.
> 
> I deleted the text representing my value judgement on space/complexity
> savings.
> 
> >...
> >  >3280bis - Tim Polk (NIST)
> >>	A new draft has been submitted with relatively minor
> >>enhancements. Several open issues remain to be resolved. In
> >>particular, questions involving name ambiguity have been raised,
> >>particularly as they impact CRL validation.
> >
> >
> >Please delete:
> >>  We may deal with this issue by adding text in the security
> considerations
> >>  section that discusses this issue.
> >
> >Replace with: "This issue will need to be discused in the security
> >considerations
> >section and it has been proposed to add an informative annex for
> explaining
> >in more depth the issue and the solutions.
> 
> I will not make this requested change as I do not believe that it
> accurately reflects the resolution of the discussion.
> 
> >...
> >
> >3280bis - Open Issues - Denis Pinkas (Bull)
> >
> >>	Denis reviewed seven topics that he considers open issues. He
> >>suggests that text on TA key update should be explicitly covered
> >>here, not just a reference to RFC 2510. He also suggests that we
> >>align out text with the latest X.509 technical corrigendum, with
> >
> >Replace with :
> >"find a better compromise with the latest X.509 technical
corrigendum, "]
> 
> done
> 
> >  >respect to key usage. Denis reviewed the name ambiguity debate
that
> >>has taken place on the list. He suggested that the private key usage
> >>extension not be deprecated universally, but rather be allowed in
> >>certain contexts, e.g., time stamp crypto modules.
> >
> >It has been proposed to soften the prohibition against private key
usage
> >or to delete annex D.1. (and thus annex D) which is the only section
that
> >adresses this topic.
> 
> done.
> 
> >
> >>  Denis asked for a
> >>simplified revocation status checking algorithm description, that
> >>addresses only the PKIX-mandated certificate extensions. He also
> >>suggests clarification of the text that says what CRLs are
> >>"available" in the local cache. Finally, Denis discussed several
> >>subtle issues associated with indirect CRLs. At the microphone a
> >>series of individuals responded to Denis's suggestions, most
> >>disagreed with one of more of his points.
> >
> >Delete the remaining of the sentence which is:
> >
> >>, although there appeared to
> >  >be agreement to soften the prohibition against private key usage.
> 
> done.
> 
> >  >
> >>
> >>Related Specifications & Liaison Presentations
> >>
> >>CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf
> >>of ETSI TC ESI)
> >>	This document is based on RFC 3126 and is aligned with a
> >>re-issue of ETSI TS 101 733. CAdES is a new name, intended to
> >>distinguish it from the XML-based version spec.
> >
> >Add: XAdES.
> >
> >"Denis said that the document is now presenting the basic electronic
> >signature formats
> >in the main body of the document while placing the features to
> >achieve the maintenance
> >of long term signatures in informative annexes. So the informative
> >annexes may equally be
> >interresting".
> >
> I reworded this slightly and added it to the XAdES section.
> 
> Steve

Cc: <[email-masked]>
From: Joel Rees <[email-masked]>
Subject: Re: defined format for renewal requests?
Date: Tue, 9 Aug 2005 20:40:38 +0900
To: Anders Rundgren <[email-masked]>
Sender: [email-masked]

On 平成 17/08/09, at 16:45, Anders Rundgren wrote:

> Joel,
>
> AFAIK a CSR does not authenticate the subscriber.  That is, the CSRs
> origin is verified out OOB using a method that the CA considers  
> suitable.

Right.

> For renewals it seems logical to use the soon-to-be-expired  
> certificate
> as authentication.

That's what I expect to do.

> There are BTW two different use-cases hidden here.
> 1) Certificate renewal.
> 2) Certificate "cloning".

Not sure what you mean by cloning.

I am aware of the difference between renewing to roll the key over,  
renewing while keeping the same key, and renewing for policy or usage  
changes.

> I agree that a renewal CSR option would be nice because then the  
> original
> certificate (c|w)ould also be deleted.

So I'm safe in understanding that there are no recommended practices  
or true standards in that regard?

> Note, the latter would have to be
> implemented as an "atomic" operation in order to not create more  
> troubles
> than it was supposed to solve...

I've been assuming we would set a policy such that once a renewed  
certificate was in the VA's (Is Validation Authority in in-company  
invention?) database, the old certificate would be considered invalid  
for signing. I suppose that would require putting the old certificate  
in the CRL us "suspended", but I don't recall an appropriate standard  
reason.

It's an internal system, so we don't have to maintain standards  
compatibility, but I do want to keep the options open if there are  
any recognized best practices that don't involve mind-reading the big  
players' documentation.

> In fact, current CSR schemes are much too primitive for serious  
> uses and
> have thus been replaced by custom solutions in many cases.  For  
> example
> there is no standard way of identifying the "key container" or define
> PIN-code policies in spite of being high on most CAs whish-lists.
>
> The biggest problem is that the entire CSR-stuff is convoluted by  
> proprietary
> methods such as Microsoft's XENROLL, making progress in this area  
> hard.

I sure wish Microsoft could learn that when they let their cattle  
water upstream, they're gonna end up drinking the polluted water  
downstream just like the rest of us.

Thanks, Anders.

> Anders Rundgren
> Security Architect
>
>
> ----- Original Message -----
> From: "Joel Rees" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, August 09, 2005 07:51
> Subject: defined format for renewal requests?
>
>
>
> Apologies in advance for the noise.
>
> I've done quick searches on what looked like the relevant RFCs and
> not really found much more than a suggestion that the renewal request
> be the same as the original certificate request. (Which would imply
> that the RA would check the database for existing certificates and
> treat, for instance, a CSR for a DN already in the database as a
> request for renewal, perhaps if it is some policy specified number of
> days before expiration? but that would seem to conflict with
> something else I read about requiring an error response if a CSR for
> a DN already issued is received.)
>
> I did find RFC 2797, and I'm trying to digest it, but a quick search
> for the word "renew" turned up
>
>     No special services are provided for doing either renewal (new
>     certificates with the same key) or re-keying (new certificates on
> new
>     keys) of clients.  Instead a renewal/re-key message looks the
> same as
>     any enrollment message, with the identity proof being supplied by
>     existing certificates from the CA.
>
> but this looks at first blush like definitions of protocols between
> servers, say the LRA and the CA?
>
> Is this perhaps primarily an implementation detail?
>
> I was thinking perhaps of defining a custom, system internal
> extension to the CSR, containing simply a flag that says this is a
> renewal request, to eliminate ambiguity. But I seem to remember that
> CSRs are v1 and thus would not have extensions?
>
> And, while I'm being the noisy newbie here, is automatic renewal
> generally preferred in implementations where there are no specific
> policy issues that would require the certificate subject to actively
> request the renewal? I've read parts of a thread or two in the
> archives that seemed to contain an assumption that renewal requests
> were not considered ordinary procedure.

Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, "Joel Rees" <[email-masked]>
Subject: Re: defined format for renewal requests?
Date: Tue, 9 Aug 2005 09:45:44 +0200
Sender: [email-masked]

Joel,

AFAIK a CSR does not authenticate the subscriber.  That is, the CSRs
origin is verified out OOB using a method that the CA considers suitable.

For renewals it seems logical to use the soon-to-be-expired certificate
as authentication.

There are BTW two different use-cases hidden here.
1) Certificate renewal.
2) Certificate "cloning".

I agree that a renewal CSR option would be nice because then the original
certificate (c|w)ould also be deleted.  Note, the latter would have to be
implemented as an "atomic" operation in order to not create more troubles
than it was supposed to solve...

In fact, current CSR schemes are much too primitive for serious uses and
have thus been replaced by custom solutions in many cases.  For example
there is no standard way of identifying the "key container" or define
PIN-code policies in spite of being high on most CAs whish-lists.

The biggest problem is that the entire CSR-stuff is convoluted by proprietary
methods such as Microsoft's XENROLL, making progress in this area hard.

Anders Rundgren
Security Architect

----- Original Message -----
From: "Joel Rees" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 09, 2005 07:51
Subject: defined format for renewal requests?

Apologies in advance for the noise.

I've done quick searches on what looked like the relevant RFCs and
not really found much more than a suggestion that the renewal request
be the same as the original certificate request. (Which would imply
that the RA would check the database for existing certificates and
treat, for instance, a CSR for a DN already in the database as a
request for renewal, perhaps if it is some policy specified number of
days before expiration? but that would seem to conflict with
something else I read about requiring an error response if a CSR for
a DN already issued is received.)

I did find RFC 2797, and I'm trying to digest it, but a quick search
for the word "renew" turned up

    No special services are provided for doing either renewal (new
    certificates with the same key) or re-keying (new certificates on
new
    keys) of clients.  Instead a renewal/re-key message looks the
same as
    any enrollment message, with the identity proof being supplied by
    existing certificates from the CA.

but this looks at first blush like definitions of protocols between
servers, say the LRA and the CA?

Is this perhaps primarily an implementation detail?

I was thinking perhaps of defining a custom, system internal
extension to the CSR, containing simply a flag that says this is a
renewal request, to eliminate ambiguity. But I seem to remember that
CSRs are v1 and thus would not have extensions?

And, while I'm being the noisy newbie here, is automatic renewal
generally preferred in implementations where there are no specific
policy issues that would require the certificate subject to actively
request the renewal? I've read parts of a thread or two in the
archives that seemed to contain an assumption that renewal requests
were not considered ordinary procedure.

--
Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

To: [email-masked]
From: Joel Rees <[email-masked]>
Subject: defined format for renewal requests?
Date: Tue, 9 Aug 2005 14:51:38 +0900
Sender: [email-masked]

Apologies in advance for the noise.

I've done quick searches on what looked like the relevant RFCs and  
not really found much more than a suggestion that the renewal request  
be the same as the original certificate request. (Which would imply  
that the RA would check the database for existing certificates and  
treat, for instance, a CSR for a DN already in the database as a  
request for renewal, perhaps if it is some policy specified number of  
days before expiration? but that would seem to conflict with  
something else I read about requiring an error response if a CSR for  
a DN already issued is received.)

I did find RFC 2797, and I'm trying to digest it, but a quick search  
for the word "renew" turned up

    No special services are provided for doing either renewal (new
    certificates with the same key) or re-keying (new certificates on  
new
    keys) of clients.  Instead a renewal/re-key message looks the  
same as
    any enrollment message, with the identity proof being supplied by
    existing certificates from the CA.

but this looks at first blush like definitions of protocols between  
servers, say the LRA and the CA?

Is this perhaps primarily an implementation detail?

I was thinking perhaps of defining a custom, system internal  
extension to the CSR, containing simply a flag that says this is a  
renewal request, to eliminate ambiguity. But I seem to remember that  
CSRs are v1 and thus would not have extensions?

And, while I'm being the noisy newbie here, is automatic renewal  
generally preferred in implementations where there are no specific  
policy issues that would require the certificate subject to actively  
request the renewal? I've read parts of a thread or two in the  
archives that seemed to contain an assumption that renewal requests  
were not considered ordinary procedure.

--
Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

Date: Mon, 8 Aug 2005 16:15:46 -0400
To: "Denis Pinkas" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: draft minutes for comment
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Denis,

>...
>  >SRV RR otherName - Stefan Santesson (Microsoft)
>>	An individual submission, now being adopted by PKIX. The
>>proposal specifies a way to embed a pointer to a DNS SRV record in a
>>certificate, to securely bind the DNS record to a named entity, using
>>the otherName type of GeneralName to carry the specific SRV RR query
>>string. Denis noted that this proposal is a somewhat odd use of the
>>subject alt name, in that the string is not the name of the
>>certificate subject, but the name of a service provided by this
>>subject.
>
>Add:
>
>"Denis proposed to use the subject directory attributes extension"
>which is well suited to carry this kind of extension..

I'll add the first line.

>...
>
>Russ said a few words about the patent issue. I would not dare to say it,
>but it would be useful for the WG to know what was said in the room.

I added ytext re Russ's comments on the IPR issue.

>...
>SCVP - Open Issues - Denis Pinkas (Bull)
>
>>	Denis emphasizes the need for thin clients, e.g., on cell
>>phones, to be supported. Denis suggested that several OPTIONAL fields
>>should be omitted to facilitate thin client support. However, because
>>these are optional, it appears that the document can be worded to
>>ensure that they impose no burden on a client that does not wish to
>>invoke them. Denis would like to see a facility to allow per-trust
>>anchor validation parameters, obviously not for thin clients, since
>>only a sophisticated client would be able to take advantage of this
>>facility. Denis also would like to represent both the validation
>  >policy and validation algorithm into a single OID,
>
>Please delete: "although this seems to yield a minor space/complexity saving",
>since the topic is much more important than space saving.

I deleted the text representing my value judgement on space/complexity savings.

>...
>  >3280bis - Tim Polk (NIST)
>>	A new draft has been submitted with relatively minor
>>enhancements. Several open issues remain to be resolved. In
>>particular, questions involving name ambiguity have been raised,
>>particularly as they impact CRL validation. 
>
>
>Please delete:
>>  We may deal with this issue by adding text in the security considerations
>>  section that discusses this issue.
>
>Replace with: "This issue will need to be discused in the security 
>considerations
>section and it has been proposed to add an informative annex for explaining
>in more depth the issue and the solutions.

I will not make this requested change as I do not believe that it 
accurately reflects the resolution of the discussion.

>...
>
>3280bis - Open Issues - Denis Pinkas (Bull)
>
>>	Denis reviewed seven topics that he considers open issues. He
>>suggests that text on TA key update should be explicitly covered
>>here, not just a reference to RFC 2510. He also suggests that we
>>align out text with the latest X.509 technical corrigendum, with
>
>Replace with :
>"find a better compromise with the latest X.509 technical corrigendum, "]

done

>  >respect to key usage. Denis reviewed the name ambiguity debate that
>>has taken place on the list. He suggested that the private key usage
>>extension not be deprecated universally, but rather be allowed in
>>certain contexts, e.g., time stamp crypto modules.
>
>It has been proposed to soften the prohibition against private key usage
>or to delete annex D.1. (and thus annex D) which is the only section that
>adresses this topic.

done.

>
>>  Denis asked for a
>>simplified revocation status checking algorithm description, that
>>addresses only the PKIX-mandated certificate extensions. He also
>>suggests clarification of the text that says what CRLs are
>>"available" in the local cache. Finally, Denis discussed several
>>subtle issues associated with indirect CRLs. At the microphone a
>>series of individuals responded to Denis's suggestions, most
>>disagreed with one of more of his points.
>
>Delete the remaining of the sentence which is:
>
>>, although there appeared to
>  >be agreement to soften the prohibition against private key usage.

done.

>  >
>>
>>Related Specifications & Liaison Presentations
>>
>>CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf
>>of ETSI TC ESI)
>>	This document is based on RFC 3126 and is aligned with a
>>re-issue of ETSI TS 101 733. CAdES is a new name, intended to
>>distinguish it from the XML-based version spec.
>
>Add: XAdES.
>
>"Denis said that the document is now presenting the basic electronic 
>signature formats
>in the main body of the document while placing the features to 
>achieve the maintenance
>of long term signatures in informative annexes. So the informative 
>annexes may equally be
>interresting".
>
I reworded this slightly and added it to the XAdES section.

Steve

Date: Mon, 8 Aug 2005 15:55:40 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: last call for SIM
Sender: [email-masked]

As per discussions at the IETF meetings last week, I am initiating WG 
last call on this document:

Internet X.509 Public Key Infrastructure Subject Identification 
Method (SIM) <draft-ietf-pkix-sim-05.txt>

Although we received a few suggestions for changes, these can be 
folded in during last call, rather than  waiting for a 06 draft.

The last call will be for 2 weeks.  I will be away on vacation when 
it ends.  Tim has recused himself from this last call since he is a 
co-author. So, when I return from vacation and plow through all the 
e-mail, I'll get back to the list on this topic, after labor day 
(Sept 6).

Steve

Date: Mon, 8 Aug 2005 15:36:59 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Qualified Certificate Requests - RFC
Cc: <[email-masked]>
Sender: [email-masked]

Anders,

You may choose to redefine terms in your circle of friends, but for 
purposes of the list let's stick with terms that are widely accepted. 
In this case, the term has a meaning relevant to the PKI context, and 
it is not the one you espouse.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'pkix'" <[email-masked]>
Subject: RE: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 8 Aug 2005 14:26:59 -0400
Importance: Normal
Sender: [email-masked]

Denis,

See the responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, August 08, 2005 12:49 PM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: RE: 3280bis: suggested words for ambiguous DNs and
delegated CRLs

Santosh,

>Denis,

>I agree that the rule of an ancestor may not be sufficient (specially 
>theoretically).  An alternative is to permit only the following:

>1.  Indirect CRL is signed using the same trust anchor DN as the 
>certificate certification path; or

Your sentence above is not crystal clear to me. 
If you only mean "same TA", then this is insufficient.

[Santosh: Let us say that the certification path for the certificate begins
with a trust anchor whose subject DN is X, then an indirect CRL can be
signed by a trust anchor whose subject DN is X.  Please note that the keys
need not be the same due to the trust anchor re-key.]

>2.  Indirect CRL is signed using an authority that is issued a 
>certificate by the same trust anchor DN as the certificate 
>certification path; or

The same applies.

[Santosh: Let us say that the certification path for the certificate begins
with a trust anchor whose subject DN is X, then an indirect CRL can be
signed by an authority which is issued a certificate by a trust anchor where
trust anchor subject DN = X.]

>3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this 
>case, depending on the reason for indirect CRL, the revocation status 
>of the delegation certificate may need to contain no check or verified 
>using partitioned CRL.

I can't understand.

[Santosh: What part you do not understand?  Delegation or revocation status
checking of the indirect CRL issuer certificate?]

>The implementations I know that use Indirect CRL are consistent with 
>the above.  But, it a further constraint/profiling/change to the 
>Standard.

???

>BTW, what are the examples of "locally known constraints" and/or how 
>would you articulate these in an RFC?

Quite hard to articulate these in an RFC. The only *example* I have in mind
is 
a validation policy that is using a *single* TA, where that TA imposes to 
the CAs it certifies some naming constraints, and where these CA also impose

naming constraints on subsequent CAs. The naming constraints may be such 
that there cannot be name collisions *if these naming constraints are really

followed*.

Denis

>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Friday, August 05, 2005 7:50 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>>Tom,
>
>>That would be fine for indirect CRL.
>
>This is insufficient, unless additional naming constrains are localy 
>known.
>
>> I assume you are not recommending this
>>for a direct CRL (i.e., when Cert Issuer = CRL issuer)
>
>>From: Tom Gindin [mailto:[email-masked]]
>>Sent: Thursday, August 04, 2005 9:38 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated 
>>CRLs
>>
>>        Santosh:
>>
>>        Actually, I have been arguing for requiring the CRL issuer's 
>>certification path to be a subset of the subject certificate's path.  
>>I
>
>Unless additional naming constrains are localy known, this may be 
>insecure.
>
>Denis
>
>>don't see any major issue if the hierarchical superior of a CA issues 
>>a CRL signing certificate which can issue CRL's for the subordinate 
>>CA's. However, I don't see how to go beyond that.
>>
>>Tom Gindin
>
>>"Santosh Chokhani" <[email-masked]>
>>Sent by: [email-masked]
>>08/03/2005 10:17 AM
>> 
>>        To:     "'pkix'" <[email-masked]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and

>>delegated CRLs
>>
>>
>>
>>Tom Gindin,
>>
>>You seem to be arguing for matching CRL certification path with that 
>>of the certificate.
>>
>>If so, you will not get an argument from me.
>>
>>[mailto:[email-masked]]
>>On
>>Behalf Of Tom Gindin
>>Sent: Tuesday, August 02, 2005 11:17 PM
>>To: Manger, James H; [email-masked]
>>Cc: pkix
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>
>>
>>        James, Santosh:
>>
>>        You certainly can construct unambiguous names for CA's, and I 
>>think that Denis already knows that (Permanent Identifier is certainly 
>>a way of constructing unambiguous names, for example).  The difficulty 
>>we have is when one issuer issues a certificate to an organizational 
>>CA with a subject name which is convenient and in common use for its 
>>organization,
>>
>>but ambiguous, and then a different issuer issues a certificate to an 
>>organizational CA with the same subject name which is also in common 
>>use for its organization.  This case is most common when both 
>>organizations use an acronym.  I do not see why the issuers of the two 
>>organizational CA
>>
>>certificates should be assumed to originate at different trust 
>>anchors, although they will be different issuers.  In fact, I don't 
>>understand why organizational name collisions are thought to be much 
>>rarer with a "common
>>
>>trust anchor" than with "different trust anchors" if the actual 
>>issuers
>>of
>>
>>the colliding certificates are both public CA's.
>>        Such collisions will have negative effects in other parts of
>>the
>>global PKI, of course.  However, unless we are prepared to issue guidance 
>>to deprecate the assignment of DN's for organizations with geographical 
>>scopes wider than the one for which they are registered and guaranteed to 
>>be unique (and many existing CA certificates have such DN's), I don't see 
>>how we can be certain or nearly certain that such collisions won't occur. 
>>A typical example of what I mean by an organization having a DN with a 
>>geographical scope wider than the one for which it's registered is a 
>>corporation registered in a single American state and operating in several

>>
>>states while having a DN without the stateOrProvinceName attribute.
>>
>>                Tom Gindin
>>
>>
>>
>>
>>
>>
>>"Manger, James H" <[email-masked]>
>>Sent by: [email-masked]
>>08/01/2005 11:05 PM
>> 
>>        To:     "pkix" <[email-masked]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and

>>
>>delegated CRLs
>>
>>
>>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know
>>the
>>trust anchors environment of the relying parties to know if the CRL issuer

>>
>>DN will be unambiguous.]
>>You can construct unambiguous DNs regardless of trust anchors.  For 
>>instance, including DC components can make a DN as unambiguous as a 
>>DNS name.  As another example, the following DN
>>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>>is unambiguous as it lists a registered business name, its Australian
>>Business Number (ABN) and the jurisdiction where those are unambiguous 
>>(Australia).  It is inconceivable that any CA could issue such a DN to 
>>another entity in good faith.
>>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>>issuing CA, but would be ambiguous in a wider context so it should not be 
>>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>>instance.
>>
>>
>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Regards,

Denis Pinkas

To: [email-masked]
Subject: Delay on 3770bis
From: Sam Hartman <[email-masked]>
Date: Mon, 08 Aug 2005 11:58:17 -0400
Sender: [email-masked]

Hi.  The chairs have proposed what I think will be resolution for the
discuss on 3770bis.  However I failed to get ahold of the AD holding
the discuss before he went on vacation, so we'll have around a one
week delay.

Date: Mon, 8 Aug 2005 17:49:23 +0100
From: "Denis Pinkas" <[email-masked]>
To: "'pkix'" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Subject: Re: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Sender: [email-masked]

Santosh,

>Denis,

>I agree that the rule of an ancestor may not be sufficient (specially
>theoretically).  An alternative is to permit only the following:

>1.  Indirect CRL is signed using the same trust anchor DN as the certificate
>certification path; or

Your sentence above is not crystal clear to me. 
If you only mean "same TA", then this is insufficient.

>2.  Indirect CRL is signed using an authority that is issued a certificate
>by the same trust anchor DN as the certificate certification path; or

The same applies.

>3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this case,
>depending on the reason for indirect CRL, the revocation status of the
>delegation certificate may need to contain no check or verified using
>partitioned CRL.

I can't understand.

>The implementations I know that use Indirect CRL are consistent with the
>above.  But, it a further constraint/profiling/change to the Standard.

???

>BTW, what are the examples of "locally known constraints" and/or how would
>you articulate these in an RFC?

Quite hard to articulate these in an RFC. The only *example* I have in mind is 
a validation policy that is using a *single* TA, where that TA imposes to 
the CAs it certifies some naming constraints, and where these CA also impose 
naming constraints on subsequent CAs. The naming constraints may be such 
that there cannot be name collisions *if these naming constraints are really 
followed*.

Denis

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Denis Pinkas
>Sent: Friday, August 05, 2005 7:50 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
>CRLs
>
>
>
>>Tom,
>
>>That would be fine for indirect CRL.
>
>This is insufficient, unless additional naming constrains are localy known.
>
>> I assume you are not recommending this
>>for a direct CRL (i.e., when Cert Issuer = CRL issuer)
>
>>From: Tom Gindin [mailto:[email-masked]]
>>Sent: Thursday, August 04, 2005 9:38 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>        Santosh:
>>
>>        Actually, I have been arguing for requiring the CRL issuer's
>>certification path to be a subset of the subject certificate's path.  I 
>
>Unless additional naming constrains are localy known, this may be insecure.
>
>Denis
>
>>don't see any major issue if the hierarchical superior of a CA issues a
>>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>>However, I don't see how to go beyond that.
>>
>>Tom Gindin
>
>>"Santosh Chokhani" <[email-masked]>
>>Sent by: [email-masked]
>>08/03/2005 10:17 AM
>> 
>>        To:     "'pkix'" <[email-masked]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>>delegated CRLs
>>
>>
>>
>>Tom Gindin,
>>
>>You seem to be arguing for matching CRL certification path with that of
>>the
>>certificate.
>>
>>If so, you will not get an argument from me.
>>
>>[mailto:[email-masked]]
>>On
>>Behalf Of Tom Gindin
>>Sent: Tuesday, August 02, 2005 11:17 PM
>>To: Manger, James H; [email-masked]
>>Cc: pkix
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>
>>
>>        James, Santosh:
>>
>>        You certainly can construct unambiguous names for CA's, and I
>>think that Denis already knows that (Permanent Identifier is certainly a 
>>way of constructing unambiguous names, for example).  The difficulty we 
>>have is when one issuer issues a certificate to an organizational CA with 
>>a subject name which is convenient and in common use for its organization, 
>>
>>but ambiguous, and then a different issuer issues a certificate to an
>>organizational CA with the same subject name which is also in common use 
>>for its organization.  This case is most common when both organizations 
>>use an acronym.  I do not see why the issuers of the two organizational CA 
>>
>>certificates should be assumed to originate at different trust anchors,
>>although they will be different issuers.  In fact, I don't understand why 
>>organizational name collisions are thought to be much rarer with a "common 
>>
>>trust anchor" than with "different trust anchors" if the actual issuers 
>>of
>>
>>the colliding certificates are both public CA's.
>>        Such collisions will have negative effects in other parts of 
>>the
>>global PKI, of course.  However, unless we are prepared to issue guidance 
>>to deprecate the assignment of DN's for organizations with geographical 
>>scopes wider than the one for which they are registered and guaranteed to 
>>be unique (and many existing CA certificates have such DN's), I don't see 
>>how we can be certain or nearly certain that such collisions won't occur. 
>>A typical example of what I mean by an organization having a DN with a 
>>geographical scope wider than the one for which it's registered is a 
>>corporation registered in a single American state and operating in several 
>>
>>states while having a DN without the stateOrProvinceName attribute.
>>
>>                Tom Gindin
>>
>>
>>
>>
>>
>>
>>"Manger, James H" <[email-masked]>
>>Sent by: [email-masked]
>>08/01/2005 11:05 PM
>> 
>>        To:     "pkix" <[email-masked]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>>
>>delegated CRLs
>>
>>
>>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>>the
>>trust anchors environment of the relying parties to know if the CRL issuer 
>>
>>DN will be unambiguous.]
>>You can construct unambiguous DNs regardless of trust anchors.  For
>>instance, including DC components can make a DN as unambiguous as a DNS 
>>name.  As another example, the following DN
>>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>>is unambiguous as it lists a registered business name, its Australian 
>>Business Number (ABN) and the jurisdiction where those are unambiguous 
>>(Australia).  It is inconceivable that any CA could issue such a DN to 
>>another entity in good faith.
>>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>>issuing CA, but would be ambiguous in a wider context so it should not be 
>>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>>instance.
>>
>>
>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Regards,

Denis Pinkas

Date: Mon, 8 Aug 2005 17:39:40 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: Re: draft minutes for comment
Sender: [email-masked]

Steve,

A few coments.

>PKIX WG Meeting 8/2/05
>
>Edited by Steve Kent
>
>Chairs: Stephen Kent <[email-masked]> & Tim Polk <[email-masked]>
>
>The PKIX WG met once during the 63nd IETF. A total of approximately 
>53 individuals participated in the meeting.
>
>
>Document status - Tim Polk (NIST)
>
>	Two new RFCs (PK Algorithms and Permanent Identifier) have 
>been issued since the last meeting. Four additional documents have 
>been approved by the IESG and are in the RFC editor's queue 
>(Certificate path building, warranty extension, 2510bis and 2511bis). 
>Three documents are being reviewed by the ADs (AC policies, CertStire 
>HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
>SIM will be initiated after this IETF meeting. More detailed 
>discussions of 3280bis and SCVP will follow. (see slides)
>
>PKIX WG Document Presentations
>
>
>SRV RR otherName - Stefan Santesson (Microsoft)
>	An individual submission, now being adopted by PKIX. The 
>proposal specifies a way to embed a pointer to a DNS SRV record in a 
>certificate, to securely bind the DNS record to a named entity, using 
>the otherName type of GeneralName to carry the specific SRV RR query 
>string. Denis noted that this proposal is a somewhat odd use of the 
>subject alt name, in that the string is not the name of the 
>certificate subject, but the name of a service provided by this 
>subject. 

Add:

"Denis proposed to use the subject directory attributes extension" 
which is well suited to carry this kind of extension..

> Others objected to this specific way of binding service 
>authorization info to a certificate, vs. other approaches, e.g., EKU, 
>or other subject alt name forms. There was general agreement that the 
>proposal needs to be carefully vetted by DNS experts. (see slides)

>Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
>	IPR issues have been resolved since the last IETF meeting, 
>but the core specification has not changed significantly since the 
>-18 draft. The draft meets most of the requirements specified in RFC 
>3379, but return of (relayed) SCVP responses was not included. This 
>will be fixed in the next draft. Also, the conformance requirements 
>seem to impose undue burdens on all clients, contrary to the goal of 
>supporting thin clients. Remaining open issues will be discussed on 
>the list, e.g., syntax details. (see slides)

Russ said a few words about the patent issue. I would not dare to say it, 
but it would be useful for the WG to know what was said in the room.

>3280bis Open Issues - Denis Pinkas (Bull)

SCVP - Open Issues - Denis Pinkas (Bull)

>	Denis emphasizes the need for thin clients, e.g., on cell 
>phones, to be supported. Denis suggested that several OPTIONAL fields 
>should be omitted to facilitate thin client support. However, because 
>these are optional, it appears that the document can be worded to 
>ensure that they impose no burden on a client that does not wish to 
>invoke them. Denis would like to see a facility to allow per-trust 
>anchor validation parameters, obviously not for thin clients, since 
>only a sophisticated client would be able to take advantage of this 
>facility. Denis also would like to represent both the validation 
>policy and validation algorithm into a single OID, 

Please delete: "although this seems to yield a minor space/complexity saving", 
since the topic is much more important than space saving. 

> although this seems to yield a minor space/complexity savings. 

> It was agreed that 
>the URI pointer to a policy will be deleted. Is also was agreed that 
>the terms "validation policy" and "validation algorithm" need to be 
>better defined in the document.
>
>3280bis - Tim Polk (NIST)
>	A new draft has been submitted with relatively minor 
>enhancements. Several open issues remain to be resolved. In 
>particular, questions involving name ambiguity have been raised, 
>particularly as they impact CRL validation.  

Please delete: 
> We may deal with this issue by adding text in the security considerations 
> section that discusses this issue. 

Replace with: "This issue will need to be discused in the security considerations 
section and it has been proposed to add an informative annex for explaining 
in more depth the issue and the solutions.

> The text has been changed to clarify what 
>conforming CAs MUST do in issuing a certificate, vs. what conforming 
>RPs MUST do re certificate path processing. The path validation 
>algorithm notes that it accepts paths that are X.509 compliant, but 
>not PKIX compliant, in support of interoperability.

>SCVP Open Issues - Denis Pinkas (Bull)

3280bis - Open Issues - Denis Pinkas (Bull)

>	Denis reviewed seven topics that he considers open issues. He 
>suggests that text on TA key update should be explicitly covered 
>here, not just a reference to RFC 2510. He also suggests that we
>align out text with the latest X.509 technical corrigendum, with 

Replace with : 
"find a better compromise with the latest X.509 technical corrigendum, "

>respect to key usage. Denis reviewed the name ambiguity debate that 
>has taken place on the list. He suggested that the private key usage 
>extension not be deprecated universally, but rather be allowed in 
>certain contexts, e.g., time stamp crypto modules. 

It has been proposed to soften the prohibition against private key usage 
or to delete annex D.1. (and thus annex D) which is the only section that 
adresses this topic.

> Denis asked for a 
>simplified revocation status checking algorithm description, that 
>addresses only the PKIX-mandated certificate extensions. He also 
>suggests clarification of the text that says what CRLs are 
>"available" in the local cache. Finally, Denis discussed several 
>subtle issues associated with indirect CRLs. At the microphone a 
>series of individuals responded to Denis's suggestions, most 
>disagreed with one of more of his points.

Delete the remaining of the sentence which is:
 
>, although there appeared to 
>be agreement to soften the prohibition against private key usage.
>
>
>Related Specifications & Liaison Presentations
>
>CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
>of ETSI TC ESI)
>	This document is based on RFC 3126 and is aligned with a 
>re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
>distinguish it from the XML-based version spec.

Add: XAdES.

"Denis said that the document is now presenting the basic electronic signature formats 
in the main body of the document while placing the features to achieve the maintenance 
of long term signatures in informative annexes. So the informative annexes may equally be 
interresting".

>XKMS - Stephen Farrell (on behalf of W3C)
>	This presentation noted that the XKMS specification in W3C 
>was completed and multiple interoperable implementations are being 
>tested. Interested PKIX members are encouraged to visit the W3C web 
>site and review the spec.

End of revised comments,

Denis

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Fri, 5 Aug 2005 08:45:27 -0400
Importance: Normal
Sender: [email-masked]

Denis,

I agree that the rule of an ancestor may not be sufficient (specially
theoretically).  An alternative is to permit only the following:

1.  Indirect CRL is signed using the same trust anchor DN as the certificate
certification path; or

2.  Indirect CRL is signed using an authority that is issued a certificate
by the same trust anchor DN as the certificate certification path; or

3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this case,
depending on the reason for indirect CRL, the revocation status of the
delegation certificate may need to contain no check or verified using
partitioned CRL.

The implementations I know that use Indirect CRL are consistent with the
above.  But, it a further constraint/profiling/change to the Standard.

BTW, what are the examples of "locally known constraints" and/or how would
you articulate these in an RFC?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, August 05, 2005 7:50 AM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
CRLs

>Tom,

>That would be fine for indirect CRL.

This is insufficient, unless additional naming constrains are localy known.

> I assume you are not recommending this
>for a direct CRL (i.e., when Cert Issuer = CRL issuer)

>From: Tom Gindin [mailto:[email-masked]]
>Sent: Thursday, August 04, 2005 9:38 AM
>To: Santosh Chokhani
>Cc: 'pkix'
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>        Santosh:
>
>        Actually, I have been arguing for requiring the CRL issuer's
>certification path to be a subset of the subject certificate's path.  I 

Unless additional naming constrains are localy known, this may be insecure.

Denis

>don't see any major issue if the hierarchical superior of a CA issues a
>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>However, I don't see how to go beyond that.
>
>Tom Gindin

>"Santosh Chokhani" <[email-masked]>
>Sent by: [email-masked]
>08/03/2005 10:17 AM
> 
>        To:     "'pkix'" <[email-masked]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of
>the
>certificate.
>
>If so, you will not get an argument from me.
>
>[mailto:[email-masked]]
>On
>Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [email-masked]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>
>but ambiguous, and then a different issuer issues a certificate to an
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>
>certificates should be assumed to originate at different trust anchors,
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>
>trust anchor" than with "different trust anchors" if the actual issuers 
>of
>
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of 
>the
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[email-masked]>
>Sent by: [email-masked]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[email-masked]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>the
>trust anchors environment of the relying parties to know if the CRL issuer 
>
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>instance.
>
>
>
>
>

Regards,

Denis Pinkas

Date: Fri, 5 Aug 2005 12:50:14 +0100
From: "Denis Pinkas" <[email-masked]>
To: "'pkix'" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Sender: [email-masked]

>Tom,

>That would be fine for indirect CRL.  

This is insufficient, unless additional naming constrains are localy known.

> I assume you are not recommending this
>for a direct CRL (i.e., when Cert Issuer = CRL issuer)

>From: Tom Gindin [mailto:[email-masked]] 
>Sent: Thursday, August 04, 2005 9:38 AM
>To: Santosh Chokhani
>Cc: 'pkix'
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>        Santosh:
>
>        Actually, I have been arguing for requiring the CRL issuer's 
>certification path to be a subset of the subject certificate's path.  I 

Unless additional naming constrains are localy known, this may be insecure.

Denis

>don't see any major issue if the hierarchical superior of a CA issues a 
>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>However, I don't see how to go beyond that.
>
>Tom Gindin

>"Santosh Chokhani" <[email-masked]>
>Sent by: [email-masked]
>08/03/2005 10:17 AM
> 
>        To:     "'pkix'" <[email-masked]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of 
>the
>certificate.
>
>If so, you will not get an argument from me.
>
>From: [email-masked] [mailto:[email-masked]] 
>On
>Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [email-masked]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I 
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>
>but ambiguous, and then a different issuer issues a certificate to an 
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>
>certificates should be assumed to originate at different trust anchors, 
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>
>trust anchor" than with "different trust anchors" if the actual issuers of 
>
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of the 
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[email-masked]>
>Sent by: [email-masked]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[email-masked]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
>trust anchors environment of the relying parties to know if the CRL issuer 
>
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For 
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>instance.
>
>
>
>
>

Regards,

Denis Pinkas

content-class: urn:content-classes:message
Subject: Freeware Certificate Management Library (CML)
Date: Thu, 4 Aug 2005 18:51:39 -0400
From: "Pawling, John" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

All,

The freeware, open-source Version 2.5 Certificate Management Library
(CML) for Microsoft Windows, Sun Solaris and Linux is freely available
at:
<http://www.digitalnet.com/knowledge/cml_home.htm>.

Applications requiring Public Key Infrastructure (PKI) security services
can use the CML to meet their X.509 certificate and Certificate
Revocation List (CRL) processing requirements. The CML provides X.509
certification path building and validation services through a
developer-friendly C and C++ Application Programming Interface (API).  

The CML performs all of the required certification path processing as
specified in X.509 Recommendation (2000) and IETF PKIX RFC 3280
Certificate/CRL Profile. The CML is capable of building certification
paths through simple and complex PKI topologies including hierarchical,
mesh, and bridge topologies, and any combination of the same.  The CML
has been successfully used to Public Key Enable (PKE) a variety of
applications to meet their X.509 certificate processing requirements.  

The CML supports digital signature verification using a variety of
cryptographic algorithms.  It supports revocation checking using CRLs
and the On-Line Certificate Status Protocol (OCSP). The accompanying
Storage and Retrieval Library (SRL) optionally provides local
certificate and CRL storage management functions.  The SRL also
optionally provides remote directory retrieval capabilities using the
Lightweight Directory Access Protocol (LDAP).  

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations
can use the CML without paying any royalties or licensing fees.  BAE
Systems is
enhancing and supporting the CML under contract to the U.S. Government.
The U.S. Government is furnishing the CML software at no cost to the
vendor subject to the conditions of the CML Public License provided with
the CML software.
  
The v2.5 CML Abstract Syntax Notation.1 (ASN.1) encodes and decodes
X.509 Certificates, CRLs and Attribute Certificates.  It requires the
v1.7 Enhanced SNACC ASN.1 software that is freely available from: 
<http://www.digitalnet.com/knowledge/snacc_home.htm>

The CML has been thoroughly tested including validating X.509
Certificates and CRLs created by a variety of Certification Authority
(CA) products, and signed using the Digital Signature Algorithm (DSA)
and RSA algorithms.  Further enhancements, ports and testing of the CML
are still in process.  Further releases of the CML will be provided as
significant capabilities are added. 

Public Key Interoperability Test Suite (PKITS) Testing: PKITS is a
comprehensive X.509 path validation test suite designed to cover most of
the features specified in X.509 and RFC 3280.  The National Institute of
Standards and Technology (NIST) is providing PKITS at 
<http://csrc.nist.gov/pki/testing/x509paths.html>. The CML was used to
successfully build and validate the X.509 certification paths included
in PKITS.

CML v2.5 includes the following enhancements (compared to v2.4 CML
release):

1. Enhanced path validation functions to allow a date to be specified
which is used as the validation date/time.
 
2. Added capability to return CRLs or OCSP responses that are used
during certificate path validation. 

3. Added Online Certificate Status Protocol (OCSP) client library, using
OpenSSL, to check revocation status of certificates using OCSP. 

4. Added new path validation error code, CM_INVALID_POLICY_MAPPING, that
is returned when a CA cert contains an invalid policy mapping (i.e.
either a policy is mapped from or to the special any-policy.)

The CML makes calls to PKCS #11-compliant libraries for cryptographic
support. BAE Systems provides a PKCS #11 implementation of Wei Dai's
Crypto++ <http://www.eskimo.com/~weidai/cryptlib.html> for use with the
CML. The underlying, external crypto libraries are not distributed as
part of the CML software. 

The CML has been successfully tested with the v2.5 S/MIME Freeware
Library (SFL) that is freely available from 
<http://www.DigitalNet.com/knowledge/sfl_home.htm>. 

The CML has been successfully tested with the v2.5 Access Control
Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml> and a CML mail list which is used to: 
distribute information regarding CML releases; discuss CML-related
issues; and allow CML users to provide feedback, comments, bug reports,
etc. Subscription information for the imc-cml mailing list is at the IMC
web site listed above. 

All comments regarding the CML source code and documents are welcome.
This CML release announcement was sent to several mail lists, but please
send all messages regarding the CML to the imc-cml mail list ONLY.
Please do not send messages regarding the CML to any of the IETF mail
lists. We will respond to all messages sent to the imc-cml mail list. 

=============================
John Pawling
BAE SYSTEMS Information Technology
[email-masked]
=============================

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Qualified Certificate Requests - RFC
Date: Thu, 4 Aug 2005 22:29:19 +0200
Sender: [email-masked]

TPMs are actually used in contexts outside of trustedcomputingroup (which
I BTW am a member of).  TPMs do not by definition have to be in HW but we
are unlikely to see much SW versions except for reference designs.
A TPM does not by definition have to bolted to a motherboard to perform
useful functions.  That is, TPMs can do many other things than protecting
operating systems including secure crypto operations on user keys in the same
was as typically associated with smart cards and HSMs.

Smart cards OTOH is not only an soon-to-be obsoleted technology, but also
a meaningless term, as "smart" does not say anything about its functionality.
Sounds more like a marketing phrase to me.  

It takes a NIST, GSA and a DoD to come up with "smart" card readers for $234:
http://www.karbonsystems.com/BlackBerry-SMIME-CAC-products_detail-83.html
when a TPM-based scheme will soon be for free and add zero weight to a mobile unit.
In addition to supporting a magnitude more use cases than a discrete card is able to.

Regarding the privacy issue with binding certs to TPM IDs including
serial number, the comparison with Intel's removed CPU number
is pretty flawed as the binding in the former case is only known by the CA
while the in the Intel case, more or less any program could read and use this
information.  In case you have a privacy issue also with the CA, I suggest
that you run it yourself.

/anders

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 04, 2005 09:40
Subject: Re: Qualified Certificate Requests - RFC

At 9:12 AM +0200 8/4/05, Anders Rundgren wrote:
>Stephen,
>Your suggestion seems to be the right way of doing this.
>
>I would though equip each TPM [1] with a unique certificate containing
>the device serial number etc.   This has the advantage that a CA may
>record this data together with other issuance data making it possible
>to trace credential misuses (theft) down to a particular "container".
>
>Regarding the name of the RFC, "Qualified Certificate Request", I would
>not associate this with qualified certificates in the EU sense, as TPM
>requirements is by no means limited to this particular class of certificates.
>
>Anders Rundgren
>
>1] Trusted Processing Module is becoming the collective term for things
>that were previously known as smart card or HSM

More accurately, TPM is a reference to a set of hardware functions 
that are intended for inclusion in general purpose computers, as 
defined by the Trusted Computing Group 
(www.trustedcomputinggroup.org/home). Smart cards and most HSMs would 
not qualify under this more precise use of the acronym.

Also note that the creation of a cert bound to a device serial 
number, at least for PCs, is precisely the sort of concept that got 
Intel a lot of bad PR a few years ago.

Steve

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked], [email-masked]
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
Date: Thu, 4 Aug 2005 15:45:37 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hi,

> I should've qualified the statement. Its clear now I've read the full
> details that a certificate isn't appopriate to sign the public key of a
> smart card key. Where it might be appropriate is in signing the vendor's
> key for trust purposes, see below.

Ok.

> So how does a CA processing the CSR and vendor key know that it can
> trust the vendor's key?

The vendor has to undergo an audit to proof the security and trustworthyness 
of the system and the vendor�s operations.
That audit can be done by any third party (Common Criteria would be an idea 
here, FIPS certification would be good too), or by the CA itself (to reduce 
the costs).

> That's a case where I believe certificates could have a role. An
> authority could certify each vendor key and the vendor would include
> references to this information in the form of a URI on its site.

Yes, that�s also possible to use authorities who certify the vendor key.
Anyway, there has to be a relationship between the vendor and the CA, I think. 
An external audit or approval by an authority just helps in that 
relationship, but I wouldn�t suggest to do it anonymously.

I think even the CA has to proof to the authorities that the overall solution 
(both the CA and the SmartCard, ...) is good enough for qualified 
certificates to be issued. So both CA and Vendor might have to be audited 
together by the authority ...

Regards,
Philipp G�hring

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Thu, 4 Aug 2005 09:44:06 -0400
Importance: Normal
Sender: [email-masked]

Tom,

That would be fine for indirect CRL.  I assume you are not recommending this
for a direct CRL (i.e., when Cert Issuer = CRL issuer)

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Thursday, August 04, 2005 9:38 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs

        Santosh:

        Actually, I have been arguing for requiring the CRL issuer's 
certification path to be a subset of the subject certificate's path.  I 
don't see any major issue if the hierarchical superior of a CA issues a 
CRL signing certificate which can issue CRL's for the subordinate CA's. 
However, I don't see how to go beyond that.

Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
08/03/2005 10:17 AM
 
        To:     "'pkix'" <[email-masked]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs

Tom Gindin,

You seem to be arguing for matching CRL certification path with that of 
the
certificate.

If so, you will not get an argument from me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, August 02, 2005 11:17 PM
To: Manger, James H; [email-masked]
Cc: pkix
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs

        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 

but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 

certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 

trust anchor" than with "different trust anchors" if the actual issuers of 

the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 

states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin

"Manger, James H" <[email-masked]>
Sent by: [email-masked]
08/01/2005 11:05 PM
 
        To:     "pkix" <[email-masked]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 

delegated CRLs

[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 

DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
instance.

To: "Santosh Chokhani" <[email-masked]>
Cc: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
From: Tom Gindin <[email-masked]>
Date: Thu, 4 Aug 2005 09:38:11 -0400
Sender: [email-masked]

        Santosh:

        Actually, I have been arguing for requiring the CRL issuer's 
certification path to be a subset of the subject certificate's path.  I 
don't see any major issue if the hierarchical superior of a CA issues a 
CRL signing certificate which can issue CRL's for the subordinate CA's. 
However, I don't see how to go beyond that.

Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
08/03/2005 10:17 AM
 
        To:     "'pkix'" <[email-masked]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs

Tom Gindin,

You seem to be arguing for matching CRL certification path with that of 
the
certificate.

If so, you will not get an argument from me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, August 02, 2005 11:17 PM
To: Manger, James H; [email-masked]
Cc: pkix
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs

        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 

but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 

certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 

trust anchor" than with "different trust anchors" if the actual issuers of 

the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 

states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin

"Manger, James H" <[email-masked]>
Sent by: [email-masked]
08/01/2005 11:05 PM
 
        To:     "pkix" <[email-masked]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 

delegated CRLs

[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 

DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
instance.

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Thu, 4 Aug 2005 06:51:15 -0400
Importance: Normal
Sender: [email-masked]

Denis,

Thanks for agreeing that RFC for my approach is simple and the approach is
not complex (You capture the rules in 2 sentences below).

Now, for the alternative as to what the relying party knows about each PKI,
what would you say in an RFC?  Please provide specific words.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Thursday, August 04, 2005 5:58 AM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
CRLs

>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of 
>the certificate.
>
>If so, you will not get an argument from me.

Matching the CRL certification path with that of the target certificate is
certainly secure. However, after some discussions with some PKIX members, it
appears that is can be made 
more general without loosing any security.

If the same TA is used and the same sequence of CA DNs (below that TA) is
used, 
then it is always secure.

Now if the RP locally "knows" some additional naming rules that apply to
every CA below 
each trusted TA from the validation policy that is being used, then this
rule may not be necessary.

Denis

>[mailto:[email-masked]] On Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [email-masked]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated 
>CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>but ambiguous, and then a different issuer issues a certificate to an 
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>certificates should be assumed to originate at different trust anchors, 
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>trust anchor" than with "different trust anchors" if the actual issuers of 
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of the 
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[email-masked]>
>Sent by: [email-masked]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[email-masked]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>the
>trust anchors environment of the relying parties to know if the CRL issuer 
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For 
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>instance.
>
>

Regards,

Denis Pinkas

Content-class: urn:content-classes:message
Subject: RE: srv based names
Date: Thu, 4 Aug 2005 10:49:03 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Kurt,

Thank you for pointing to this relevant document.

Looking at the draft, and also the IESG log raises some concerns though.
It seems to me that the content in the dns URI and the SRV RR, even
though seems identical, is defined with different semantics and that is
also the source of concerns raised in IESG.

While the domain part of the SRV RR query string refers to the domain
where the service resides, the dns host name in the URI specifies host
name of the dns server.

The difference seems to me is that I can use the SRV RR query to ask any
locally configured DNS to resolve the location of the requested service
on the requested domain, the URI on the other hand points specifically
to the dns server which holds a specific record.

I think we should keep a close eye on the progress of the dns URI draft
but I don't see that it for now should prevent us from proceeding with
the proposed otherName definition.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: den 4 augusti 2005 10:25
> To: Stefan Santesson
> Cc: Russ Housley; [email-masked]
> Subject: RE: srv based names
> 
> I note that the IESG is considering:
> http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-12.txt
> 
> Given the ability to write this service identification
> information as the URL:
>         dns:///_kerberos._tcp.example.com?class=IN;type=SRV
> 
> in a certificate, why we need another way express this
> service identification information in a certificate.
> 
> Kurt
> 
> 
> At 07:56 AM 8/4/2005, Stefan Santesson wrote:
> >The mechanism of SRV RR corresponds to domain names so names are not
> >ambiguous.
> >
> >The SRV RR is interesting as a way to approach a domain searching for
> >appropriate recourses/services on that domain. That service may or
may
> >not correspond to a URI scheme, but it will always correspond to a
> >specific SRV tag (or you could not search for it).
> >
> >What do you gain by preventing me from binding to that service name
in a
> >cert?
> >
> >Stefan Santesson
> >Program Manager, Standards Liaison
> >Windows Security
> >
> >
> >> From: Kurt D. Zeilenga [mailto:[email-masked]]
> >> Sent: den 4 augusti 2005 02:18
> >> To: Stefan Santesson
> >> Cc: Russ Housley; [email-masked]
> >> Subject: RE: srv based names
> >>
> >> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
> >>
> >> >Manual validation by users is hardly the target here.
> >> >It rather a way for a client application to determine that it has
> >reached
> >> a host that is authorized to deliver the service it searched for.
> >>
> >> I see no reason why uniformResourceIdentifier cannot be used
> >> for this excepting for the point that the current set of
> >> URI schemes is insufficient.
> >>
> >> I think it for more appropriate to engineer additional
> >> URI schemes where needed than to use the strings intended
> >> to be used to locate DNS SRV RR records as a more general
> >> service identifier than they were intended to be.
> >>
> >> It was noted your proposal was intended for use with
> >> Kerberos.  I find this quite problematic given that
> >> "EXAMPLE.COM" and "example.com" are two different
> >> realms but one domain.  That is, the string
> >> _kerberos._tcp.example.com is ambiguous.
> >>
> >> Consider a realm called "REALM.TLD" (picking TLD for some
> >> reason other than it being a valid TLD) operating using
> >> non DNS SRV based location services and a client attempting
> >> to verify that the server it contacted has an appropriate
> >> issued certificate.  That client is not only configured
> >> with knowledge of the CA which issued the certificate
> >> for this service, but a collection of other trusted CAs.
> >> An attacker can register REALM.TLD and then get one
> >> of the other trusted CAs to issue a certificate to a
> >> rough service.
> >>
> >> Now, it might be argued that this example is a bit
> >> contrived, however I think it illustrates a class of
> >> problems one will find using names of DNS RRs as
> >> alt subjects.
> >>
> >> >If you approach a service knowing its SRV service name then
binding
> >to
> >> that SRV name is most appropriate and functional.
> >>
> >> To know the name of the SRV RR implies knowledge of
> >> service-specific service information, such as a realm in
> >> the Kerberos case and an ability to map this
> >> information to a (purported) name of a DNS SRV RR.
> >> Just because one can map a realm to a (purported) name
> >> of a DNS SRV RR does mean it is appropriate to use the
> >> result of this mapping as a subject identifier in a
> >> certificate.  In the case of Kerberos, I think it
> >> can be argued that the (purported) name of a DNS
> >> SRV RR should not be used, or only used when the
> >> service location policy for that realm is DNS SRV.
> >> If the service location policy was to use a configured
> >> location, use of the (purported) name would be
> >> inappropriate.
> >>
> >> I argue it is far more appropriate to use the
> >> service-specific information in the subject identifier.
> >> That is, use the Kerberos realm as the subject identifier.
> >> Why wouldn't a Kerberos realm URI scheme met your needs
> >> in this case?
> >>
> >> Kurt

Date: Thu, 4 Aug 2005 10:57:50 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Re: AW: Qualified Certificate Requests - RFC
Sender: [email-masked]

Philipp,

Yes, there is something wrong in that method, as described below. 
It would be insecure to use a single vendor public key for all 
the smart cards from that vendor.

Denis

>Hello,
>
>> how do you imagine a "qualified CSR"? The problem is, that a CA must get a
>> prove that the CSR is generated by a smartcard or an HSM and not by a peace
>> of fake software.
>> Until now, IMHO, there's no feasible concept to prove that.
>
>My concept is the following:
>
>First the SmartCard vendor generates a public/private keypair, the so-called 
>vendorkey.
>
>When the SmardCard (or HSM) is manufactured (or initialized), the private 
>vendorkey is burnt into the SmartCard.
>The SmartCard has to enforce two things:
>  The private vendor key can�t leave the SmartCard
>  The private vendor key can only be used to sign public keys, for which the 
>corresponding private key�s were generated in the SmartCard, and are also 
>securely stored in it.
>
>The SmartCard (and it�s vendor) has to be audited (by a third party auditor, 
>or by the CA).
>When the audit succeeds, the CA approves the public vendorkey for qualified 
>certificates.
>
>Now the user buys the SmartCard.
>
>Then the user let�s the SmartCard generate a User-Keypair.
>The SmartCard signs the user�s public-key with the vendor�s secret key.
>The software requests both the user-public key and the signature of the users
>�s public key from the Smartcard.
>The software generates a certificate request for the User-Keypair, and 
>includes the signature as a extension (or attribute) in the request.
>
>The certificate request is sent to the CA in the normal way.
>
>The CA detects the qualification signature, verifies it against the public key 
>of the vendor, and if everyhting matches, the CA can issue a qualified 
>signature.
>
>Anything wrong in that method?
>
>Regards,
>Philipp G�hring

Date: Thu, 4 Aug 2005 10:57:36 +0100
From: "Denis Pinkas" <[email-masked]>
To: "'pkix'" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Sender: [email-masked]

>Tom Gindin,
>
>You seem to be arguing for matching CRL certification path with that of the
>certificate.
>
>If so, you will not get an argument from me.

Matching the CRL certification path with that of the target certificate is certainly secure.
However, after some discussions with some PKIX members, it appears that is can be made 
more general without loosing any security.

If the same TA is used and the same sequence of CA DNs (below that TA) is used, 
then it is always secure.

Now if the RP locally "knows" some additional naming rules that apply to every CA below 
each trusted TA from the validation policy that is being used, then this rule may not
be necessary.

Denis

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Tom Gindin
>Sent: Tuesday, August 02, 2005 11:17 PM
>To: Manger, James H; [email-masked]
>Cc: pkix
>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>
>        James, Santosh:
>
>        You certainly can construct unambiguous names for CA's, and I 
>think that Denis already knows that (Permanent Identifier is certainly a 
>way of constructing unambiguous names, for example).  The difficulty we 
>have is when one issuer issues a certificate to an organizational CA with 
>a subject name which is convenient and in common use for its organization, 
>but ambiguous, and then a different issuer issues a certificate to an 
>organizational CA with the same subject name which is also in common use 
>for its organization.  This case is most common when both organizations 
>use an acronym.  I do not see why the issuers of the two organizational CA 
>certificates should be assumed to originate at different trust anchors, 
>although they will be different issuers.  In fact, I don't understand why 
>organizational name collisions are thought to be much rarer with a "common 
>trust anchor" than with "different trust anchors" if the actual issuers of 
>the colliding certificates are both public CA's.
>        Such collisions will have negative effects in other parts of the 
>global PKI, of course.  However, unless we are prepared to issue guidance 
>to deprecate the assignment of DN's for organizations with geographical 
>scopes wider than the one for which they are registered and guaranteed to 
>be unique (and many existing CA certificates have such DN's), I don't see 
>how we can be certain or nearly certain that such collisions won't occur. 
>A typical example of what I mean by an organization having a DN with a 
>geographical scope wider than the one for which it's registered is a 
>corporation registered in a single American state and operating in several 
>states while having a DN without the stateOrProvinceName attribute.
>
>                Tom Gindin
>
>
>
>
>
>
>"Manger, James H" <[email-masked]>
>Sent by: [email-masked]
>08/01/2005 11:05 PM
> 
>        To:     "pkix" <[email-masked]>
>        cc: 
>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
>trust anchors environment of the relying parties to know if the CRL issuer 
>DN will be unambiguous.]
>You can construct unambiguous DNs regardless of trust anchors.  For 
>instance, including DC components can make a DN as unambiguous as a DNS 
>name.  As another example, the following DN
>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>is unambiguous as it lists a registered business name, its Australian 
>Business Number (ABN) and the jurisdiction where those are unambiguous 
>(Australia).  It is inconceivable that any CA could issue such a DN to 
>another entity in good faith.
>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>issuing CA, but would be ambiguous in a wider context so it should not be 
>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>instance.
>
>

Regards,

Denis Pinkas

Date: Thu, 04 Aug 2005 04:54:15 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: Where to story srv based names
Sender: [email-masked]

[ Speaking as a PKIX WG member and document author. ]

I do not want to see names appear in subjectDirectoryAttributes.  Not 
everything that can be done should be done.  If we agree that a standard is 
appropriate at all, I strongly prefer subjectAltName.

Date: Thu, 04 Aug 2005 10:25:17 +0200
To: "Stefan Santesson" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: srv based names
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I note that the IESG is considering:
http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-12.txt

Given the ability to write this service identification
information as the URL:
        dns:///_kerberos._tcp.example.com?class=IN;type=SRV

in a certificate, why we need another way express this
service identification information in a certificate.

Kurt

At 07:56 AM 8/4/2005, Stefan Santesson wrote:
>The mechanism of SRV RR corresponds to domain names so names are not
>ambiguous.
>
>The SRV RR is interesting as a way to approach a domain searching for
>appropriate recourses/services on that domain. That service may or may
>not correspond to a URI scheme, but it will always correspond to a
>specific SRV tag (or you could not search for it).
>
>What do you gain by preventing me from binding to that service name in a
>cert?
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
> 
>
>> From: Kurt D. Zeilenga [mailto:[email-masked]]
>> Sent: den 4 augusti 2005 02:18
>> To: Stefan Santesson
>> Cc: Russ Housley; [email-masked]
>> Subject: RE: srv based names
>> 
>> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
>> 
>> >Manual validation by users is hardly the target here.
>> >It rather a way for a client application to determine that it has
>reached
>> a host that is authorized to deliver the service it searched for.
>> 
>> I see no reason why uniformResourceIdentifier cannot be used
>> for this excepting for the point that the current set of
>> URI schemes is insufficient.
>> 
>> I think it for more appropriate to engineer additional
>> URI schemes where needed than to use the strings intended
>> to be used to locate DNS SRV RR records as a more general
>> service identifier than they were intended to be.
>> 
>> It was noted your proposal was intended for use with
>> Kerberos.  I find this quite problematic given that
>> "EXAMPLE.COM" and "example.com" are two different
>> realms but one domain.  That is, the string
>> _kerberos._tcp.example.com is ambiguous.
>> 
>> Consider a realm called "REALM.TLD" (picking TLD for some
>> reason other than it being a valid TLD) operating using
>> non DNS SRV based location services and a client attempting
>> to verify that the server it contacted has an appropriate
>> issued certificate.  That client is not only configured
>> with knowledge of the CA which issued the certificate
>> for this service, but a collection of other trusted CAs.
>> An attacker can register REALM.TLD and then get one
>> of the other trusted CAs to issue a certificate to a
>> rough service.
>> 
>> Now, it might be argued that this example is a bit
>> contrived, however I think it illustrates a class of
>> problems one will find using names of DNS RRs as
>> alt subjects.
>> 
>> >If you approach a service knowing its SRV service name then binding
>to
>> that SRV name is most appropriate and functional.
>> 
>> To know the name of the SRV RR implies knowledge of
>> service-specific service information, such as a realm in
>> the Kerberos case and an ability to map this
>> information to a (purported) name of a DNS SRV RR.
>> Just because one can map a realm to a (purported) name
>> of a DNS SRV RR does mean it is appropriate to use the
>> result of this mapping as a subject identifier in a
>> certificate.  In the case of Kerberos, I think it
>> can be argued that the (purported) name of a DNS
>> SRV RR should not be used, or only used when the
>> service location policy for that realm is DNS SRV.
>> If the service location policy was to use a configured
>> location, use of the (purported) name would be
>> inappropriate.
>> 
>> I argue it is far more appropriate to use the
>> service-specific information in the subject identifier.
>> That is, use the Kerberos realm as the subject identifier.
>> Why wouldn't a Kerberos realm URI scheme met your needs
>> in this case?
>> 
>> Kurt

Date: Thu, 4 Aug 2005 03:40:55 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Qualified Certificate Requests - RFC
Cc: <[email-masked]>
Sender: [email-masked]

At 9:12 AM +0200 8/4/05, Anders Rundgren wrote:
>Stephen,
>Your suggestion seems to be the right way of doing this.
>
>I would though equip each TPM [1] with a unique certificate containing
>the device serial number etc.   This has the advantage that a CA may
>record this data together with other issuance data making it possible
>to trace credential misuses (theft) down to a particular "container".
>
>Regarding the name of the RFC, "Qualified Certificate Request", I would
>not associate this with qualified certificates in the EU sense, as TPM
>requirements is by no means limited to this particular class of certificates.
>
>Anders Rundgren
>
>1] Trusted Processing Module is becoming the collective term for things
>that were previously known as smart card or HSM

More accurately, TPM is a reference to a set of hardware functions 
that are intended for inclusion in general purpose computers, as 
defined by the Trusted Computing Group 
(www.trustedcomputinggroup.org/home). Smart cards and most HSMs would 
not qualify under this more precise use of the acronym.

Also note that the creation of a cert bound to a device serial 
number, at least for PCs, is precisely the sort of concept that got 
Intel a lot of bad PR a few years ago.

Steve

Date: Thu, 4 Aug 2005 03:25:12 -0400
To: David Chadwick <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Where to story srv based names
Cc: "Kurt D. Zeilenga" <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Sender: [email-masked]

At 5:28 PM +0100 8/3/05, David Chadwick wrote:
>Steve
>
>as everyone at the meeting seemed to agree (I did not hear any 
>dissent on this point), was that the SRV name was an attribute of 
>the certificate holder.
>
>The discussion then ranged over what is the best place to store this 
>attribute in the certificate.
>
>Dennis suggested the subjectDirectoryAttributes extension. You 
>disagreed  and one of your reasons was that an OID would be needed 
>for this. But an OID is also needed for the subjectAltName 
>extension. So this cannot be a valid reason for discounting 
>subjectDirectoryAttributes. You also said that the attribute may not 
>be stored in a directory, but that also is not a valid reason for 
>not using this extension. There are many attribute types defined in 
>X.520 (and some RFCs) that are never actually stored in the 
>directory :-)

I suggested that storing a DNS-centric attribute in the X.500 
directory was anomalous, and merely noted that the lack of an 
existing OID for such an attribute was indicative of this being 
anomalous. Of course one can assign an OID for anything, but that 
does not make it appropriate :-).  Also, as Stefan noted in his 
reply, I'm not sure that this extension is widely used in any uniform 
fashion, since it is a catch-all that could contain a wide range of 
arbitrary data.

>I agree with Dennis for the following reasons.
>
>i) using the subjectDirectoryAttributes extension allows you to 
>define this attribute in a complete and compact way. This is what we 
>actually want to do, regardless of whether it is stored in the 
>directory or not. In particular, we need to specify the matching 
>rules for the attribute value. How is the value stored in the DNS RR 
>to be compared with the value stored in the cert. Bitstring 
>comparison? Case ignore string comparison? Defining the attribute as 
>a directory attribute will ensure that you cover this point 
>properly. If you define it as a subjectAltName extension you will 
>still need to specify the matching rules. Have you thought of that?

I agree that we need to specify matching rules, but one need not make 
this string a directory attribute to specify matching rules. After 
all, the DNS has matching rules for its entries. Assigning an OID and 
using the existing subject directory attribute extension would be 
compact, but I'm not sure how much weight to give to that 
consideration.

>2) if the attribute is defined as a directory attribute, then we 
>also have the option of storing it in the directory, and creating a 
>virtuous circle as shown in the attached diagram. The DNS SRV RR 
>points to a field in the cert, and this points to an attribute in 
>the directory, and this directory entry can point to the DNS.

An interesting observation, but it would be more compelling if we had 
some text explaining how this cyclic linkage improves security, as 
opposed to opportunities for creating more things that have to be 
maintained in synch.

Steve

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Henson" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Qualified Certificate Requests - RFC
Date: Thu, 4 Aug 2005 09:12:47 +0200
Sender: [email-masked]

Stephen,
Your suggestion seems to be the right way of doing this.

I would though equip each TPM [1] with a unique certificate containing
the device serial number etc.   This has the advantage that a CA may
record this data together with other issuance data making it possible
to trace credential misuses (theft) down to a particular "container".

Regarding the name of the RFC, "Qualified Certificate Request", I would
not associate this with qualified certificates in the EU sense, as TPM
requirements is by no means limited to this particular class of certificates.

Anders Rundgren

1] Trusted Processing Module is becoming the collective term for things
that were previously known as smart card or HSM

----- Original Message -----
From: "Stephen Henson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 04, 2005 01:29
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate

Philipp G�hring wrote:

>
>>>Including a certificate as an OCTETSTRING into a CSR?
>>
>>Note the "or a reference to one" including a URI where it could be
>>downloaded would have a smaller overhead.
>
>
> The problem is that the scenario is a normal user requesting a qualified
> certificate.
> The keypair is generated directly before the request is sent. If it were
> generated by the vendor before, it would make sense to put the certs on a
> server. But that�s not the case.
> And the request should be processed as fast as possible. I don�t see where a
> normal user has a webserver available, where the PKCS#11 driver or CSP could
> upload the certificate. And I don�t think that the user will be happy doing
> that himself.
> So referencing an external certificate is not an option, I would say.
>

I should've qualified the statement. Its clear now I've read the full
details that a certificate isn't appopriate to sign the public key of a
smart card key. Where it might be appropriate is in signing the vendor's
key for trust purposes, see below.

>
>>Ah now that's another issue. Would this "vendor key" be the same on each
>>smartcard or different for each one? Presumably it would have to be
>>different for each vendor?
>
> Every vendor has his own key, or a couple of keys, perhaps one for each kind
> of device the vendor produces. Let�s say normally a vendor should have <10
> keys. But definitly not for every single device.
>

So how does a CA processing the CSR and vendor key know that it can
trust the vendor's key?

That's a case where I believe certificates could have a role. An
authority could certify each vendor key and the vendor would include
references to this information in the form of a URI on its site.

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.

Content-class: urn:content-classes:message
Subject: RE: srv based names
Date: Thu, 4 Aug 2005 06:56:36 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The mechanism of SRV RR corresponds to domain names so names are not
ambiguous.

The SRV RR is interesting as a way to approach a domain searching for
appropriate recourses/services on that domain. That service may or may
not correspond to a URI scheme, but it will always correspond to a
specific SRV tag (or you could not search for it).

What do you gain by preventing me from binding to that service name in a
cert?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: den 4 augusti 2005 02:18
> To: Stefan Santesson
> Cc: Russ Housley; [email-masked]
> Subject: RE: srv based names
> 
> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
> 
> >Manual validation by users is hardly the target here.
> >It rather a way for a client application to determine that it has
reached
> a host that is authorized to deliver the service it searched for.
> 
> I see no reason why uniformResourceIdentifier cannot be used
> for this excepting for the point that the current set of
> URI schemes is insufficient.
> 
> I think it for more appropriate to engineer additional
> URI schemes where needed than to use the strings intended
> to be used to locate DNS SRV RR records as a more general
> service identifier than they were intended to be.
> 
> It was noted your proposal was intended for use with
> Kerberos.  I find this quite problematic given that
> "EXAMPLE.COM" and "example.com" are two different
> realms but one domain.  That is, the string
> _kerberos._tcp.example.com is ambiguous.
> 
> Consider a realm called "REALM.TLD" (picking TLD for some
> reason other than it being a valid TLD) operating using
> non DNS SRV based location services and a client attempting
> to verify that the server it contacted has an appropriate
> issued certificate.  That client is not only configured
> with knowledge of the CA which issued the certificate
> for this service, but a collection of other trusted CAs.
> An attacker can register REALM.TLD and then get one
> of the other trusted CAs to issue a certificate to a
> rough service.
> 
> Now, it might be argued that this example is a bit
> contrived, however I think it illustrates a class of
> problems one will find using names of DNS RRs as
> alt subjects.
> 
> >If you approach a service knowing its SRV service name then binding
to
> that SRV name is most appropriate and functional.
> 
> To know the name of the SRV RR implies knowledge of
> service-specific service information, such as a realm in
> the Kerberos case and an ability to map this
> information to a (purported) name of a DNS SRV RR.
> Just because one can map a realm to a (purported) name
> of a DNS SRV RR does mean it is appropriate to use the
> result of this mapping as a subject identifier in a
> certificate.  In the case of Kerberos, I think it
> can be argued that the (purported) name of a DNS
> SRV RR should not be used, or only used when the
> service location policy for that realm is DNS SRV.
> If the service location policy was to use a configured
> location, use of the (purported) name would be
> inappropriate.
> 
> I argue it is far more appropriate to use the
> service-specific information in the subject identifier.
> That is, use the Kerberos realm as the subject identifier.
> Why wouldn't a Kerberos realm URI scheme met your needs
> in this case?
> 
> Kurt

Date: Thu, 04 Aug 2005 02:17:34 +0200
To: "Stefan Santesson" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: RE: srv based names
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 07:16 PM 8/3/2005, Stefan Santesson wrote:

>Manual validation by users is hardly the target here.
>It rather a way for a client application to determine that it has reached a host that is authorized to deliver the service it searched for.

I see no reason why uniformResourceIdentifier cannot be used
for this excepting for the point that the current set of
URI schemes is insufficient.

I think it for more appropriate to engineer additional
URI schemes where needed than to use the strings intended
to be used to locate DNS SRV RR records as a more general
service identifier than they were intended to be.

It was noted your proposal was intended for use with
Kerberos.  I find this quite problematic given that
"EXAMPLE.COM" and "example.com" are two different
realms but one domain.  That is, the string
_kerberos._tcp.example.com is ambiguous.

Consider a realm called "REALM.TLD" (picking TLD for some
reason other than it being a valid TLD) operating using
non DNS SRV based location services and a client attempting
to verify that the server it contacted has an appropriate
issued certificate.  That client is not only configured
with knowledge of the CA which issued the certificate
for this service, but a collection of other trusted CAs.
An attacker can register REALM.TLD and then get one
of the other trusted CAs to issue a certificate to a
rough service.

Now, it might be argued that this example is a bit
contrived, however I think it illustrates a class of
problems one will find using names of DNS RRs as
alt subjects.

>If you approach a service knowing its SRV service name then binding to that SRV name is most appropriate and functional.

To know the name of the SRV RR implies knowledge of
service-specific service information, such as a realm in
the Kerberos case and an ability to map this
information to a (purported) name of a DNS SRV RR.
Just because one can map a realm to a (purported) name
of a DNS SRV RR does mean it is appropriate to use the
result of this mapping as a subject identifier in a
certificate.  In the case of Kerberos, I think it
can be argued that the (purported) name of a DNS
SRV RR should not be used, or only used when the
service location policy for that realm is DNS SRV.
If the service location policy was to use a configured
location, use of the (purported) name would be
inappropriate.

I argue it is far more appropriate to use the
service-specific information in the subject identifier.
That is, use the Kerberos realm as the subject identifier.
Why wouldn't a Kerberos realm URI scheme met your needs
in this case? 

Kurt 

Date: Thu, 04 Aug 2005 02:15:49 +0200
To: Stephen Kent <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: srv based names
Cc: Love H�rnquist �strand  <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

At 03:38 PM 8/3/2005, Stephen Kent wrote:

>At 12:17 PM +0200 8/3/05, Love H�rnquist �strand wrote:
>>Love H�rnquist �strand <[email-masked]> writes:
>>
>>> I talked to Kurt Zeilenga after the meeting, and then understood what he
>>> was talking about. The uniformResourceIdentifier part of GeneralName (and
>>> this SubjectAltName) can be used instead of srv based names to limit what
>>> service the certificate is allowed to serve.
>>
>>to hopefully clarify,
>>
>>If the service we want to bind the certificate have a uri defined. Example:
>>jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
>>SRV-rr lookup to the service is not needed. Instead the client can bind the
>>thing that user entered (user@domain) to the certificate containing the uri
>>for the same service.
>>
>>The only problem is that services need to specify uri for itself. That
>>might not be obvious when the protocol using DNS SRV-rr is written to
>>support certificates, for example, by using TLS.
>>
>>Love
>
>The clarification is helpful, and it suggests that this solution works best if the application expresses the service name in a URI form. Many apps do that, but not all, as Russ noted.

The lack of sufficient URI schemes implies a need for
additional URI schemes, possibly a general service
URI scheme.

The lack of sufficient URI schemes does not imply that we
should use names of DNS SRVs RRs as general service identifiers.

-- Kurt

Date: Thu, 04 Aug 2005 00:29:19 +0100
From: Stephen Henson <[email-masked]>
To: [email-masked]
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
Sender: [email-masked]

Philipp G�hring wrote:

> 
>>>Including a certificate as an OCTETSTRING into a CSR?
>>
>>Note the "or a reference to one" including a URI where it could be
>>downloaded would have a smaller overhead.
> 
> 
> The problem is that the scenario is a normal user requesting a qualified 
> certificate. 
> The keypair is generated directly before the request is sent. If it were 
> generated by the vendor before, it would make sense to put the certs on a 
> server. But that�s not the case.
> And the request should be processed as fast as possible. I don�t see where a 
> normal user has a webserver available, where the PKCS#11 driver or CSP could 
> upload the certificate. And I don�t think that the user will be happy doing 
> that himself.
> So referencing an external certificate is not an option, I would say.
> 

I should've qualified the statement. Its clear now I've read the full
details that a certificate isn't appopriate to sign the public key of a
smart card key. Where it might be appropriate is in signing the vendor's
key for trust purposes, see below.

> 
>>Ah now that's another issue. Would this "vendor key" be the same on each
>>smartcard or different for each one? Presumably it would have to be
>>different for each vendor?
> 
> Every vendor has his own key, or a couple of keys, perhaps one for each kind 
> of device the vendor produces. Let�s say normally a vendor should have <10 
> keys. But definitly not for every single device.
> 

So how does a CA processing the CSR and vendor key know that it can
trust the vendor's key?

That's a case where I believe certificates could have a role. An
authority could certify each vendor key and the vendor would include
references to this information in the form of a URI on its site.

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: Philipp =?utf-8?q?G=C3=BChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked], [email-masked]
Subject: Re: AW: Qualified Certificate Requests - RFC
Date: Thu, 4 Aug 2005 00:42:45 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hans-Peter,

> Nothing is wrong with this concept 

Thanks.

> but it's not new.   

I already heard about several similar concepts:
* One complex one from Novell with a point system (abandoned, too complex)
* TPM (it could be compatible)
* IBM HSM (not officially documented)
* The first generation of Crypto iButtons (before they used Java)
* Fortezza Cards (I didn´t found information about it, but I guess that I do
   not need it anymore)

The technical model behind is not new, obviously.

But most of them are overly complex, and there is no standard way for doing 
it.
But we need a standard method now for qualified certificates, that can be used 
by all the vendors (SmartCards, HSM´s, TPM´s, other Tokens)

And we need to integrate it into the standard software now.

> You need to pay 
> attention to the different keys, though.  

What exactly do you mean?

> If you want to be able to 
> determine that the certificate request was signed by a specific smart card,
> then the number of manufacturer keys is huge.

No, I just need to make sure that it comes from a secure smart card. I don´t 
care, which one. (And I don´t want to know which one)

> The concept, as far as I am aware of, was developed by TC TrustCenter (they
> are an accredited CA in Germany).  The concept was implemented with one of
> the major HSM vendors.  I don't know which one but it might be Eracom.

Thanks for the information, I´ll ask them both about it.

Regards,
Philipp Gühring

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked], [email-masked]
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
Date: Thu, 4 Aug 2005 00:39:35 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hi,

> > Including a certificate as an OCTETSTRING into a CSR?
>
> Note the "or a reference to one" including a URI where it could be
> downloaded would have a smaller overhead.

The problem is that the scenario is a normal user requesting a qualified 
certificate. 
The keypair is generated directly before the request is sent. If it were 
generated by the vendor before, it would make sense to put the certs on a 
server. But that�s not the case.
And the request should be processed as fast as possible. I don�t see where a 
normal user has a webserver available, where the PKCS#11 driver or CSP could 
upload the certificate. And I don�t think that the user will be happy doing 
that himself.
So referencing an external certificate is not an option, I would say.

> Ah now that's another issue. Would this "vendor key" be the same on each
> smartcard or different for each one? Presumably it would have to be
> different for each vendor?

Every vendor has his own key, or a couple of keys, perhaps one for each kind 
of device the vendor produces. Let�s say normally a vendor should have <10 
keys. But definitly not for every single device.

Regards,
Philipp G�hring

Date: Wed, 03 Aug 2005 23:12:11 +0100
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Qualified Certificate Requests - Signature vs. Certificate
Sender: [email-masked]

Philipp G�hring wrote:

> Hi,
> 
> 
>>I was instead suggesting that an appropriate certificate (or a reference
>>to one) is included in the CSR. That is the signature format is a
>>certificate, with optional appropriate additional conditions.
> 
> 
> Including a certificate as an OCTETSTRING into a CSR?
> 

Note the "or a reference to one" including a URI where it could be
downloaded would have a smaller overhead.

> 
>>The format is already standardised as are mechanisms for verification,
>>policy checking and revocation. For revocation consider what would
>>happen if the key becomes compromised or inaccessible meaning a new key
>>is required.
> 
> 
> That means that you can�t use your SmartCard for any new qualified 
> certificates then.
> 

I hadn't seen the full details when I suggested a certificate. Since
I've now seen that the vendor key signs other keys generated on the
smartcard it wouldn't serve the purpose I originally thought.

It could serve a different purpose of certifying vendor keys though: see
below...

> 
> 
>>In the system you have AFAICS the trust model is for a single RSA key
>>which asserts that the key resides on a smart card. In the certificate
>>model you can have an appropriate hierarchy which can certify individual
>>manufacturers. A verifier then just has to trust a root.
> 
> Can�t the RSA key be externally linked in a X.509 or OpenPGP chain?
> 

Ah now that's another issue. Would this "vendor key" be the same on each
smartcard or different for each one? Presumably it would have to be
different for each vendor?

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: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked], [email-masked]
Subject: Qualified Certificate Requests - Signature vs. Certificate
Date: Wed, 3 Aug 2005 23:52:25 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hi,

> I was instead suggesting that an appropriate certificate (or a reference
> to one) is included in the CSR. That is the signature format is a
> certificate, with optional appropriate additional conditions.

Including a certificate as an OCTETSTRING into a CSR?

The more I think about it, the less I like that idea.
* Possibly not enough memory in SmartCards
* unnecessary overhead
* possibly interoperability issues

I am more for the keep it simple stupid method here. Let us find one good and 
simple way, and implement that everywhere.

> The "identity" can be anything appopriate. The subject DN could be empty
> and an appropriate subjectAltName identity used instead which asserts
> something appropriate. This might for example be and encoded version of
> "Foobar smart card manufacturer, FIPS140-2 level 4 card, Serial number
> 1234".

Hmm. Either a card is secure enough for qualified signatures, or not.

I even heard of a concept that had a complex point system for the 
qualification of a signature. You get points for each FIPS level, for 
biometrics, ...

But I think we should keep it as simple as possible.

That�s the only way to get it implemented, I think.

> Doing this has a number of advantages.
>
> It can be used with other signing algorithms, not just RSA.

Hmmm. That�s an interesting point.
On the other hand, if you want to use a different signing algorithm, you will 
likely have to change your hardware, which should be re-evaluated anyway.

And I don�t see a problem in assigning OID�s to every new parameter set.

> The format is already standardised as are mechanisms for verification,
> policy checking and revocation. For revocation consider what would
> happen if the key becomes compromised or inaccessible meaning a new key
> is required.

That means that you can�t use your SmartCard for any new qualified 
certificates then.

I don�t think that the hardware vendor will operate it�s own CA to publish the 
certificates, CRL�s, ...
Do you know any hardware vendor that wants to operate it�s own CA?
So I guess that the CA service for the qualified tokens would have to be done 
by the same CA, being just more work, to operate yet another root ...
The other variant would be to have the auditor operate the CA.
I also doubt that an auditor wants to run a CA. (Altough it would make sense 
to do so)

> In the system you have AFAICS the trust model is for a single RSA key
> which asserts that the key resides on a smart card. In the certificate
> model you can have an appropriate hierarchy which can certify individual
> manufacturers. A verifier then just has to trust a root.

Can�t the RSA key be externally linked in a X.509 or OpenPGP chain?

> Policy processing allows finer control over the asserted features, a
> given policy might assert additional levels of security. For example
> FIPS level 3 or higher.

Yes, it would be nice to have all information inside the request. But I don�t 
see a real need for it.
Do you know any existing policy system, where I can decide which FIPS level 
the card has to minimum have?

Any other opinions on the topic Signature vs. Certificate?

Regards,
Philipp G�hring

Content-class: urn:content-classes:message
Subject: RE: Where to story srv based names
Date: Wed, 3 Aug 2005 18:39:09 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David Chadwick" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I don't want to see this in subjectDirectoryAttributes.

A major reason is that many implementations (ours included) doesn't
parse that extension at all since it is practically not utilized.

But even despite that, I don't think this is a directory attribute and I
don't foresee it used as such. In my mind it fits much better within the
same extension as is used for URI, dnsName, IP address etc.

The matching is not dramatic. It is practically a case ignore exact
match. But you are right that we probably need to address it.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David Chadwick
> Sent: den 3 augusti 2005 09:28
> To: Stephen Kent
> Cc: Kurt D. Zeilenga; Russ Housley; [email-masked]
> Subject: Where to story srv based names
> 
> Steve
> 
> as everyone at the meeting seemed to agree (I did not hear any dissent
> on this point), was that the SRV name was an attribute of the
> certificate holder.
> 
> The discussion then ranged over what is the best place to store this
> attribute in the certificate.
> 
> Dennis suggested the subjectDirectoryAttributes extension. You
disagreed
>   and one of your reasons was that an OID would be needed for this.
But
> an OID is also needed for the subjectAltName extension. So this cannot
> be a valid reason for discounting subjectDirectoryAttributes. You also
> said that the attribute may not be stored in a directory, but that
also
> is not a valid reason for not using this extension. There are many
> attribute types defined in X.520 (and some RFCs) that are never
actually
> stored in the directory :-)
> 
> I agree with Dennis for the following reasons.
> 
> i) using the subjectDirectoryAttributes extension allows you to define
> this attribute in a complete and compact way. This is what we actually
> want to do, regardless of whether it is stored in the directory or
not.
> In particular, we need to specify the matching rules for the attribute
> value. How is the value stored in the DNS RR to be compared with the
> value stored in the cert. Bitstring comparison? Case ignore string
> comparison? Defining the attribute as a directory attribute will
ensure
> that you cover this point properly. If you define it as a
subjectAltName
> extension you will still need to specify the matching rules. Have you
> thought of that?
> 
> 2) if the attribute is defined as a directory attribute, then we also
> have the option of storing it in the directory, and creating a
virtuous
> circle as shown in the attached diagram. The DNS SRV RR points to a
> field in the cert, and this points to an attribute in the directory,
and
> this directory entry can point to the DNS.
> 
> regards
> 
> David
> 
> 
> --
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.ac.uk
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************

Content-class: urn:content-classes:message
Subject: RE: srv based names
Date: Wed, 3 Aug 2005 18:26:56 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I totally disagree.

I you approach a service knowing its URI, then binding to the URI is most appropriate.

If you approach a system with a specific e-mail address, then binding to the rfc822Name is probably most appropriate.

If you approach a service knowing its SRV service name then binding to that SRV name is most appropriate and functional.

All depends on context and what your prior knowledge is. There is no single name form that will always work.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 3 augusti 2005 07:18
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: srv based names
> 
> 
> At 02:49 PM 8/3/2005, Russ Housley wrote:
> 
> >Thanks for following up; however, I do not think that Kurt's observation
> matters in many important contexts.  Stefan made a mistake by using a
> collection of LDAP servers as an example in his slides.
> 
> I don't view it as a mistake as most protocols which use SRV RRs
> use them similar to how LDAP does.  I would have said the same
> thing if he had used http, smtp, imap, etc..
> 
> >There are other services that do not have URLs.  As the discussion in the
> meeting showed, there are services for which we do not have URIs.
> Kerberos KDC is one important example.  KRB-WG is specifying the use of
> certificates in their PK-INIT document, and the Kerberos KDC will be the
> subject of the certificate.
> 
> So create more URI schemes.   Names of SRV RRs are not, IMO,
> good service identifiers.  URIs, in particular, URLs, are.
> 
> I note that there are also services which don't have SRV support,
> one could take the argument that since some services don't have
> URIs and some services don't have SRV RRs specifications, we
> should introduce yet another service identifier form for use
> as alternative subject names in certificates.
> 
> We only need one general way of specify Internet services
> as alternative subject names.  I think URLs is the best
> general service identifier form available, certainly far
> more general than the DNS name of an SRV RR.
> 
> Kurt
> 
> 
> >Russ
> >
> >At 04:51 AM 8/3/2005, Love H�rnquist �strand wrote:
> >>I talked to Kurt Zeilenga after the meeting, and then understood what he
> >>was talking about. The uniformResourceIdentifier part of GeneralName
> (and
> >>this SubjectAltName) can be used instead of srv based names to limit
> what
> >>service the certificate is allowed to serve.
> >>
> >>Love

Content-class: urn:content-classes:message
Subject: RE: srv based names
Date: Wed, 3 Aug 2005 18:16:47 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Manual validation by users is hardly the target here.
It rather a way for a client application to determine that it has reached a host that is authorized to deliver the service it searched for.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 3 augusti 2005 07:24
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: srv based names
> 
> 
> Another problem with using the DNS name of a SRV RR as a
> service identifier is that they are totally alien to the
> user community.
> 
> URIs are not alien.  In fact, its a URI which the user
> actually sees on a side of the bus and enters into their
> user agent
> 
> What do you want your users' certificate view to see when
> manually checking the validity of a certificate (in clients
> which don't understand the necessary alternative subject
> name)?
> 
> Kurt
> 
> At 02:49 PM 8/3/2005, Russ Housley wrote:
> 
> >Thanks for following up; however, I do not think that Kurt's observation
> matters in many important contexts.  Stefan made a mistake by using a
> collection of LDAP servers as an example in his slides.  There are other
> services that do not have URLs.  As the discussion in the meeting showed,
> there are services for which we do not have URIs.  Kerberos KDC is one
> important example.  KRB-WG is specifying the use of certificates in their
> PK-INIT document, and the Kerberos KDC will be the subject of the
> certificate.
> >
> >Russ
> >
> >At 04:51 AM 8/3/2005, Love H�rnquist �strand wrote:
> >>I talked to Kurt Zeilenga after the meeting, and then understood what he
> >>was talking about. The uniformResourceIdentifier part of GeneralName
> (and
> >>this SubjectAltName) can be used instead of srv based names to limit
> what
> >>service the certificate is allowed to serve.
> >>
> >>Love

Content-class: urn:content-classes:message
Subject: RE: srv based names
Date: Wed, 3 Aug 2005 09:47:12 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> So create more URI schemes.   Names of SRV RRs are not, IMO,
> good service identifiers.  URIs, in particular, URLs, are.

The way that we create new URI schemes these days is essentially to
assign an SRV or NAPTR prefix value. NAPTR was created expressly for URN
resolution.

All an SRV record is is a substitute for a protocol port assignment. It
is not something that is alien to the IETF way of designing protocols. 

What we see on the side of a bus is usually something like www.ipod.com
or even just ipod.com. It is actually becomming rare these days to see
http://www.ipod.com/ in advertising litterature.

In the original Internet architecture a domain name stood for a machine.
Today people want the domain name to be a logical access point for a
collection of services. mailto:[email-masked] and
jabber:[email-masked] are surely both references to the same person.

In the Web world we would much rather have a URN of the form
user:[email-masked] that can stand for all the uses of the address. 

Date: Wed, 03 Aug 2005 17:28:28 +0100
From: David Chadwick <[email-masked]>
Organization: University of Kent
To: Stephen Kent <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Where to story srv based names
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070600040704010704070103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Steve

as everyone at the meeting seemed to agree (I did not hear any dissent 
on this point), was that the SRV name was an attribute of the 
certificate holder.

The discussion then ranged over what is the best place to store this 
attribute in the certificate.

Dennis suggested the subjectDirectoryAttributes extension. You disagreed 
  and one of your reasons was that an OID would be needed for this. But 
an OID is also needed for the subjectAltName extension. So this cannot 
be a valid reason for discounting subjectDirectoryAttributes. You also 
said that the attribute may not be stored in a directory, but that also 
is not a valid reason for not using this extension. There are many 
attribute types defined in X.520 (and some RFCs) that are never actually 
stored in the directory :-)

I agree with Dennis for the following reasons.

i) using the subjectDirectoryAttributes extension allows you to define 
this attribute in a complete and compact way. This is what we actually 
want to do, regardless of whether it is stored in the directory or not. 
In particular, we need to specify the matching rules for the attribute 
value. How is the value stored in the DNS RR to be compared with the 
value stored in the cert. Bitstring comparison? Case ignore string 
comparison? Defining the attribute as a directory attribute will ensure 
that you cover this point properly. If you define it as a subjectAltName 
extension you will still need to specify the matching rules. Have you 
thought of that?

2) if the attribute is defined as a directory attribute, then we also 
have the option of storing it in the directory, and creating a virtuous 
circle as shown in the attached diagram. The DNS SRV RR points to a 
field in the cert, and this points to an attribute in the directory, and 
this directory entry can point to the DNS.

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

--------------070600040704010704070103
Content-Type: image/jpeg;
 name="SRV-RR.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="SRV-RR.jpg"

--------------070600040704010704070103--

Date: Wed, 3 Aug 2005 11:28:54 -0400
To: "Kurt D. Zeilenga" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: srv based names
Cc: Russ Housley <[email-masked]>, [email-masked]
Sender: [email-masked]

At 4:24 PM +0200 8/3/05, Kurt D. Zeilenga wrote:
>Another problem with using the DNS name of a SRV RR as a
>service identifier is that they are totally alien to the
>user community.

To the extent that a user (vs. an app developer) has to deal with the 
string, I agree that URIs are much less alien, but I don't think that 
we're discussing examples where a user will be dealing with these 
values.

>URIs are not alien.  In fact, its a URI which the user
>actually sees on a side of the bus and enters into their
>user agent

"side of the bus?" A user enters a URI for web-based accesses, but 
not for all applications. Stefan's major motivation, as he noted 
later, is Kerberos, and I would not expect to see a URI used there.

>What do you want your users' certificate view to see when
>manually checking the validity of a certificate (in clients
>which don't understand the necessary alternative subject name)?

I don't think anyone is suggesting that a user will view a cert to 
perform the check. It should be automated, performed by software.  So 
the last argument above is not relevant.

Content-class: urn:content-classes:message
Subject: RE: AW: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 11:25:06 -0400
From: "Schwebler, Hans-Peter" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C5981E.001E8C50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Phillip,

Nothing is wrong with this concept but it's not new.  You need to pay
attention to the different keys, though.  If you want to be able to
determine that the certificate request was signed by a specific smart =
card,
then the number of manufacturer keys is huge. =20

The concept, as far as I am aware of, was developed by TC TrustCenter =
(they
are an accredited CA in Germany).  The concept was implemented with one =
of
the major HSM vendors.  I don't know which one but it might be Eracom.

Best regards,
Hans-Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Philipp G=FChring
Sent: Wednesday, August 03, 2005 10:58 AM
To: [email-masked]
Subject: Re: AW: Qualified Certificate Requests - RFC

Hello,

> how do you imagine a "qualified CSR"? The problem is, that a CA must =
get a
> prove that the CSR is generated by a smartcard or an HSM and not by a
peace
> of fake software.
> Until now, IMHO, there's no feasible concept to prove that.

My concept is the following:

First the SmartCard vendor generates a public/private keypair, the =
so-called

vendorkey.

When the SmardCard (or HSM) is manufactured (or initialized), the =
private=20
vendorkey is burnt into the SmartCard.
The SmartCard has to enforce two things:
  The private vendor key can=B4t leave the SmartCard
  The private vendor key can only be used to sign public keys, for which =
the

corresponding private key=B4s were generated in the SmartCard, and are =
also=20
securely stored in it.

The SmartCard (and it=B4s vendor) has to be audited (by a third party =
auditor,

or by the CA).
When the audit succeeds, the CA approves the public vendorkey for =
qualified=20
certificates.

Now the user buys the SmartCard.

Then the user let=B4s the SmartCard generate a User-Keypair.
The SmartCard signs the user=B4s public-key with the vendor=B4s secret =
key.
The software requests both the user-public key and the signature of the
users
=B4s public key from the Smartcard.
The software generates a certificate request for the User-Keypair, and=20
includes the signature as a extension (or attribute) in the request.

The certificate request is sent to the CA in the normal way.

The CA detects the qualification signature, verifies it against the =
public
key=20
of the vendor, and if everyhting matches, the CA can issue a qualified=20
signature.

Anything wrong in that method?

Regards,
Philipp G=FChring

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

------=_NextPart_000_0020_01C5981E.001E8C50--

Date: Wed, 3 Aug 2005 11:23:16 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: whoops
Sender: [email-masked]

A couple of folks have pointed out an obvious error in the minutes, 
i.e., I swapped the subjects of Denis's presentations.

Steve

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked]
Subject: Re: AW: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 16:58:27 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hello,

> how do you imagine a "qualified CSR"? The problem is, that a CA must get a
> prove that the CSR is generated by a smartcard or an HSM and not by a peace
> of fake software.
> Until now, IMHO, there's no feasible concept to prove that.

My concept is the following:

First the SmartCard vendor generates a public/private keypair, the so-called 
vendorkey.

When the SmardCard (or HSM) is manufactured (or initialized), the private 
vendorkey is burnt into the SmartCard.
The SmartCard has to enforce two things:
  The private vendor key can�t leave the SmartCard
  The private vendor key can only be used to sign public keys, for which the 
corresponding private key�s were generated in the SmartCard, and are also 
securely stored in it.

The SmartCard (and it�s vendor) has to be audited (by a third party auditor, 
or by the CA).
When the audit succeeds, the CA approves the public vendorkey for qualified 
certificates.

Now the user buys the SmartCard.

Then the user let�s the SmartCard generate a User-Keypair.
The SmartCard signs the user�s public-key with the vendor�s secret key.
The software requests both the user-public key and the signature of the users
�s public key from the Smartcard.
The software generates a certificate request for the User-Keypair, and 
includes the signature as a extension (or attribute) in the request.

The certificate request is sent to the CA in the normal way.

The CA detects the qualification signature, verifies it against the public key 
of the vendor, and if everyhting matches, the CA can issue a qualified 
signature.

Anything wrong in that method?

Regards,
Philipp G�hring

Date: Wed, 03 Aug 2005 16:24:28 +0200
To: Russ Housley <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: srv based names
Cc: [email-masked]
Sender: [email-masked]

Another problem with using the DNS name of a SRV RR as a
service identifier is that they are totally alien to the
user community.

URIs are not alien.  In fact, its a URI which the user
actually sees on a side of the bus and enters into their
user agent

What do you want your users' certificate view to see when
manually checking the validity of a certificate (in clients
which don't understand the necessary alternative subject
name)? 

Kurt

At 02:49 PM 8/3/2005, Russ Housley wrote:

>Thanks for following up; however, I do not think that Kurt's observation matters in many important contexts.  Stefan made a mistake by using a collection of LDAP servers as an example in his slides.  There are other services that do not have URLs.  As the discussion in the meeting showed, there are services for which we do not have URIs.  Kerberos KDC is one important example.  KRB-WG is specifying the use of certificates in their PK-INIT document, and the Kerberos KDC will be the subject of the certificate.
>
>Russ
>
>At 04:51 AM 8/3/2005, Love H�rnquist �strand wrote:
>>I talked to Kurt Zeilenga after the meeting, and then understood what he
>>was talking about. The uniformResourceIdentifier part of GeneralName (and
>>this SubjectAltName) can be used instead of srv based names to limit what
>>service the certificate is allowed to serve.
>>
>>Love

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Wed, 3 Aug 2005 10:17:57 -0400
Importance: Normal
Sender: [email-masked]

Tom Gindin,

You seem to be arguing for matching CRL certification path with that of the
certificate.

If so, you will not get an argument from me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Tuesday, August 02, 2005 11:17 PM
To: Manger, James H; [email-masked]
Cc: pkix
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs

        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 
but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 
certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 
trust anchor" than with "different trust anchors" if the actual issuers of 
the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 
states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin

"Manger, James H" <[email-masked]>
Sent by: [email-masked]
08/01/2005 11:05 PM
 
        To:     "pkix" <[email-masked]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs

[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 
DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
instance.

Date: Wed, 03 Aug 2005 16:17:49 +0200
To: Russ Housley <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: srv based names
Cc: [email-masked]
Sender: [email-masked]

At 02:49 PM 8/3/2005, Russ Housley wrote:

>Thanks for following up; however, I do not think that Kurt's observation matters in many important contexts.  Stefan made a mistake by using a collection of LDAP servers as an example in his slides. 

I don't view it as a mistake as most protocols which use SRV RRs
use them similar to how LDAP does.  I would have said the same
thing if he had used http, smtp, imap, etc..

>There are other services that do not have URLs.  As the discussion in the meeting showed, there are services for which we do not have URIs.  Kerberos KDC is one important example.  KRB-WG is specifying the use of certificates in their PK-INIT document, and the Kerberos KDC will be the subject of the certificate.

So create more URI schemes.   Names of SRV RRs are not, IMO,
good service identifiers.  URIs, in particular, URLs, are.

I note that there are also services which don't have SRV support,
one could take the argument that since some services don't have
URIs and some services don't have SRV RRs specifications, we
should introduce yet another service identifier form for use
as alternative subject names in certificates.

We only need one general way of specify Internet services
as alternative subject names.  I think URLs is the best
general service identifier form available, certainly far
more general than the DNS name of an SRV RR.

Kurt

>Russ
>
>At 04:51 AM 8/3/2005, Love H�rnquist �strand wrote:
>>I talked to Kurt Zeilenga after the meeting, and then understood what he
>>was talking about. The uniformResourceIdentifier part of GeneralName (and
>>this SubjectAltName) can be used instead of srv based names to limit what
>>service the certificate is allowed to serve.
>>
>>Love

From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AW: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 16:01:32 +0200 
Sender: [email-masked]

Philipp,

how do you imagine a "qualified CSR"? The problem is, that a CA must get a
prove that the CSR is generated by a smartcard or an HSM and not by a peace
of fake software.
Until now, IMHO, there's no feasible concept to prove that.

Best Regards

Thomas Beckmann

> -----Urspr�ngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]]Im Auftrag von Anders Rundgren
> Gesendet: Mittwoch, 3. August 2005 15:11
> An: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: Qualified Certificate Requests - RFC
> 
> 
> 
> Hi Philipp,
> 
> <snip>
> >For the Browser vendors it will be a short amount 
> of additional 
> >code, that I will try to offer them as easy to apply 
> patches for their code.
> <snip>
> 
> You mean that MSFT would dump their 
> proprietary Xenroll scheme? That is a hard sell.
> 
> Although I don't see 
> much vendor interest in this area at all[1], I believe that an XML-
> based "certgen" browser object triggered by a specific 
> MIME-type would 
> be considerably better than improving an outdated ASN.1 based 
> pkcs #10 
> scheme driven by arbitrary amounts of Javascript and ActiveX code. 
> 
> regards
> Anders Rundgren
> 
> 1]  In spite of the fact that web-browser-
> based on-line signatures are MUCH more used (and useful) than 
> signed e-
> mail, no browser vendor or standardization organization have to date 
> publicly not even mentioned the possibility of a standard.  There are 
> virtually HUNDREDS of proprietary signature schemes in use, including 
> the Austrian b�rgerkarte scheme:  http://www.buergerkarte.at
> 
> 
> 

Date: Wed, 3 Aug 2005 09:38:07 -0400
To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?=  <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: srv based names
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

At 12:17 PM +0200 8/3/05, Love H�rnquist �strand wrote:
>Love H�rnquist �strand <[email-masked]> writes:
>
>>  I talked to Kurt Zeilenga after the meeting, and then understood what he
>>  was talking about. The uniformResourceIdentifier part of GeneralName (and
>>  this SubjectAltName) can be used instead of srv based names to limit what
>>  service the certificate is allowed to serve.
>
>to hopefully clarify,
>
>If the service we want to bind the certificate have a uri defined. Example:
>jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
>SRV-rr lookup to the service is not needed. Instead the client can bind the
>thing that user entered (user@domain) to the certificate containing the uri
>for the same service.
>
>The only problem is that services need to specify uri for itself. That
>might not be obvious when the protocol using DNS SRV-rr is written to
>support certificates, for example, by using TLS.
>
>Love

The clarification is helpful, and it suggests 
that this solution works best if the application 
expresses the service name in a URI form. Many 
apps do that, but not all, as Russ noted.

Steve

Date: Wed, 3 Aug 2005 15:10:54 +0200 (MEST)
From: Anders Rundgren <[email-masked]>
Reply-To: Anders Rundgren <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Qualified Certificate Requests - RFC
Sender: [email-masked]

Hi Philipp,

<snip>
>For the Browser vendors it will be a short amount 
of additional 
>code, that I will try to offer them as easy to apply 
patches for their code.
<snip>

You mean that MSFT would dump their 
proprietary Xenroll scheme? That is a hard sell.

Although I don't see 
much vendor interest in this area at all[1], I believe that an XML-
based "certgen" browser object triggered by a specific MIME-type would 
be considerably better than improving an outdated ASN.1 based pkcs #10 
scheme driven by arbitrary amounts of Javascript and ActiveX code. 

regards
Anders Rundgren

1]  In spite of the fact that web-browser-
based on-line signatures are MUCH more used (and useful) than signed e-
mail, no browser vendor or standardization organization have to date 
publicly not even mentioned the possibility of a standard.  There are 
virtually HUNDREDS of proprietary signature schemes in use, including 
the Austrian b�rgerkarte scheme:  http://www.buergerkarte.at

Date: Wed, 3 Aug 2005 15:06:21 +0200 (MEST)
From: Anders Rundgren <[email-masked]>
Reply-To: Anders Rundgren <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Qualified Certificate Requests - RFC
Sender: [email-masked]

Philipp,

<snip>
>For the Browser vendors it will be a short amount of 
additional 
>code, that I will try to offer them as easy to apply 
patches for their code.
<snip>

You mean that MSFT would dump their 
proprietary Xenroll scheme? That is a hard sell.

Although I don't see 
much vendor interest in this area at all[1], I personally feel that an 
XML-based "certgen" browser object triggered by a specific MIME-type 
would be considerably better than improving an outdated ASN.1 based 
pkcs #10 scheme driven by arbitrary amounts of Javascript and ActiveX 
code. 

Anders Rundgren

1]  In spite of the fact that web-browser-
based on-line signatures are MUCH more used than signed e-mail, no 
browser vendor or standardization organization has to date publicly not 
even mentioned the possibility of a standard.  There are virtually 
HUNDREDS of proprietary schemes in use, including the Austrian 
b�rgerkarte scheme.  http://www.buergerkarte.at

Date: Wed, 03 Aug 2005 08:49:02 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: srv based names
Sender: [email-masked]

Thanks for following up; however, I do not think that Kurt's observation 
matters in many important contexts.  Stefan made a mistake by using a 
collection of LDAP servers as an example in his slides.  There are other 
services that do not have URLs.  As the discussion in the meeting showed, 
there are services for which we do not have URIs.  Kerberos KDC is one 
important example.  KRB-WG is specifying the use of certificates in their 
PK-INIT document, and the Kerberos KDC will be the subject of the certificate.

Russ

At 04:51 AM 8/3/2005, Love H�rnquist �strand wrote:
>I talked to Kurt Zeilenga after the meeting, and then understood what he
>was talking about. The uniformResourceIdentifier part of GeneralName (and
>this SubjectAltName) can be used instead of srv based names to limit what
>service the certificate is allowed to serve.
>
>Love

To: "pkix" <[email-masked]>
Subject: Re: srv based names
From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= <[email-masked]>
Date: Wed, 03 Aug 2005 12:17:15 +0200
Sender: [email-masked]

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

Love H=F6rnquist =C5strand <[email-masked]> writes:

> I talked to Kurt Zeilenga after the meeting, and then understood what he
> was talking about. The uniformResourceIdentifier part of GeneralName (and
> this SubjectAltName) can be used instead of srv based names to limit what
> service the certificate is allowed to serve.

to hopefully clarify,

If the service we want to bind the certificate have a uri defined. Example:
jabber:[node@]domain[/resource]. Then the step of its to bind the DNS
SRV-rr lookup to the service is not needed. Instead the client can bind the
thing that user entered (user@domain) to the certificate containing the uri
for the same service.

The only problem is that services need to specify uri for itself. That
might not be obvious when the protocol using DNS SRV-rr is written to
support certificates, for example, by using TLS.

Love

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

--=-=-=--

Date: Wed, 3 Aug 2005 06:07:36 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft minutes for comment
Sender: [email-masked]

PKIX WG Meeting 8/2/05

Edited by Steve Kent

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

The PKIX WG met once during the 63nd IETF. A total of approximately 
53 individuals participated in the meeting.

Document status - Tim Polk (NIST)

	Two new RFCs (PK Algorithms and Permanent Identifier) have 
been issued since the last meeting. Four additional documents have 
been approved by the IESG and are in the RFC editor's queue 
(Certificate path building, warranty extension, 2510bis and 2511bis). 
Three documents are being reviewed by the ADs (AC policies, CertStire 
HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
SIM will be initiated after this IETF meeting. More detailed 
discussions of 3280bis and SCVP will follow. (see slides)

PKIX WG Document Presentations

SRV RR otherName - Stefan Santesson (Microsoft)
	An individual submission, now being adopted by PKIX. The 
proposal specifies a way to embed a pointer to a DNS SRV record in a 
certificate, to securely bind the DNS record to a named entity, using 
the otherName type of GeneralName to carry the specific SRV RR query 
string. Denis noted that this proposal is a somewhat odd use of the 
subject alt name, in that the string is not the name of the 
certificate subject, but the name of a service provided by this 
subject. Others objected to this specific way of binding service 
authorization info to a certificate, vs. other approaches, e.g., EKU, 
or other subject alt name forms. There was general agreement that the 
proposal needs to be carefully vetted by DNS experts. (see slides)

Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
	IPR issues have been resolved since the last IETF meeting, 
but the core specification has not changed significantly since the 
-18 draft. The draft meets most of the requirements specified in RFC 
3379, but return of (relayed) SCVP responses was not included. This 
will be fixed in the next draft. Also, the conformance requirements 
seem to impose undue burdens on all clients, contrary to the goal of 
supporting thin clients. Remaining open issues will be discussed on 
the list, e.g., syntax details. (see slides)

3280bis Open Issues - Denis Pinkas (Bull)
	Denis emphasizes the need for thin clients, e.g., on cell 
phones, to be supported. Denis suggested that several OPTIONAL fields 
should be omitted to facilitate thin client support. However, because 
these are optional, it appears that the document can be worded to 
ensure that they impose no burden on a client that does not wish to 
invoke them. Denis would like to see a facility to allow per-trust 
anchor validation parameters, obviously not for thin clients, since 
only a sophisticated client would be able to take advantage of this 
facility. Denis also would like to represent both the validation 
policy and validation algorithm into a single OID, although this 
seems to yield a minor space/complexity savings. It was agreed that 
the URI pointer to a policy will be deleted. Is also was agreed that 
the terms "validation policy" and "validation algorithm" need to be 
better defined in the document.

3280bis - Tim Polk (NIST)
	A new draft has been submitted with relatively minor 
enhancements. Several open issues remain to be resolved. In 
particular, questions involving name ambiguity have been raised, 
particularly as they impact CRL validation. We may deal with this 
issue by adding text in the security considerations section that 
discusses this issue. The text has been changed to clarify what 
conforming CAs MUST do in issuing a certificate, vs. what conforming 
RPs MUST do re certificate path processing. The path validation 
algorithm notes that it accepts paths that are X.509 compliant, but 
not PKIX compliant, in support of interoperability.

SCVP Open Issues - Denis Pinkas (Bull)
	Denis reviewed seven topics that he considers open issues. He 
suggests that text on TA key update should be explicitly covered 
here, not just a reference to RFC 2510. He also suggests that we 
align out text with the latest X.509 technical corrigendum, with 
respect to key usage. Denis reviewed the name ambiguity debate that 
has taken place on the list. He suggested that the private key usage 
extension not be deprecated universally, but rather be allowed in 
certain contexts, e.g., time stamp crypto modules. Denis asked for a 
simplified revocation status checking algorithm description, that 
addresses only the PKIX-mandated certificate extensions. He also 
suggests clarification of the text that says what CRLs are 
"available" in the local cache. Finally, Denis discussed several 
subtle issues associated with indirect CRLs. At the microphone a 
series of individuals responded to Denis's suggestions, most 
disagreed with one of more of his points, although there appeared to 
be agreement to soften the prohibition against private key usage.

Related Specifications & Liaison Presentations

CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
of ETSI TC ESI)
	This document is based on RFC 3126 and is aligned with a 
re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
distinguish it from the XML-based version spec.

XKMS - Stephen Farrell (on behalf of W3C)
	This presentation noted that the XKMS specification in W3C 
was completed and multiple interoperable implementations are being 
tested. Interested PKIX members are encouraged to visit the W3C web 
site and review the spec.

Reply-To: "Julian Inza" <[email-masked]>
From: "Julian Inza" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 11:48:11 +0200
Organization: =?iso-8859-1?Q?Direcci=F3n_Privada?=
Sender: [email-masked]

Hello friends,

I completly support the position of Mr. Philipp G�hring

By the way, I have been acting as special Registration Authority Support 
Expert in order to assure in the registration process of a Qualified 
Certificates Issuer CA that a specific certificate request has been 
generated inside of a secure signature creation device.So I can atest that 
this specific need exists.

This is not only the case of smartcards but also of Hardware Security 
Modules when qualified certificates are managed in behalf of a legal 
persons.

Things would be a lot easier if the request could be backed by a device 
signature.

Best regards,

_____________________________________________________
-Juli�n Inza (mailto:[email-masked])
-President
-Interactiva (http://www.interactiva.com.es)

This e-mail message could contain CONFIDENTIAL INFORMATION  property of 
Albalia Interactiva. If received by mistake, please ignore it, delete it and 
notify the sender. Your personal information can be added to a relationships 
file (that can include marketing information) at Albalia Interactiva where 
you can exercise your rights to access, rectify or cancel your data 
according spanish 15/1999 Organic Law (Act). You are authorised to use 
personal data of the signer of this message as long as there is a way to 
exercise the mentioned rights by the signer.
_____________________________________________________

----- Original Message ----- 
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 03, 2005 10:11 AM
Subject: Re: Qualified Certificate Requests - RFC

>
> Hi,
>
> Most QCs are probably manufactured in closed processes making
> standards less applicable.
>
> For on-line generated and distributed
> certificates, practically the entire process is currently non-standard,
> beginning with browsers.   Few on-line certificate systems therefore
> use the browser stuff and have introduced their own proprietary
> methods.  These methods typically also address PIN-code policies,
> something which seems to be missing in PKCS #10.  The
> OpenMobileAlliance have created additional standards but I don't think
> these have much acceptance by browser vendors.
>
> Anders Rundgren
>
> ----
> Original Message----
> From: [email-masked]
> Date: Aug 2, 2005 10:13:55
> PM
> To: [email-masked]
> Subj: Qualified Certificate Requests - RFC
>
>
> Hello,
>
> I have been reading through the PKIX archive, and found a lot
> of interesting
> material on the topic of qualified certificates.
>
> But
> what I am completely missing is the necessary foundation of qualified
> certificate requests.
>
> Regarding the requirements for qualified
> certificates, the only obstacle I
> currently have is the problem, that
> I have to make sure, that the private key
> for the certificate is
> generated and stored securely in a SmartCard, or
> another Hardware
> Token.
>
> Since the users should be able to issue the certificates at
> home, I need a
> technical solution to make sure, that the private key
> is from within a
> SmartCard, when we receive a certificate request.
>
> Therefore I designed "Qualified Certificate Requests", which
> cryptographically
> signs the public key in the CSR with a vendor key,
> to state that it comes
> from a secure device.
>
> Now I created a software-
> based reference implementation, so that the security
> of the system can
> be evaluated, and that the Token Vendors can see how to do
> it, and can
> do interoperability testing:
>
> http://www2.futureware.
> at/svn/sourcerer/CAcert/QCSR/
>
> The following parameters are still open
> and can be changed by the vendor:
>  The crypto algorithm (we have
> chosen RSA here)
>  The encoding of the public key (we have chosen PEM
> encoding from OpenSSL)
>  The signature method (we have chosen the RSA
> signature from OpenSSL,
>     which normally gives 128 binary bytes as
> signature)
>  The encoding into the qcsr field in the CSR (I have
> chosen Hex-encoding,
>     since I didn�t found an easy way to do it
> directly binary yet)
>  The OID for the qcsr field (we have allocated a
> OID range below our range
>     for all QCSR OID�s. Feel free to contact
> me if you want an OID for your
>     parameters)
>
> If a hardware vendor
> wants to change something on the implementation, please
> provide a
> software reference-implementation, that is bit-compatible to the
> proposed hardware implementation, so that the security can be
> evaluated.
> (I guess it will be best, if it is based on our reference-
> implementation)
>
> Should qualified certificate requests be documented in
> a own RFC, or added to
> the Qualified Certificates RFC?
>
> Regards,
> Philipp G�hring
>
>
>
>
>
>
> 

To: "pkix" <[email-masked]>
Subject: srv based names
From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= <[email-masked]>
Date: Wed, 03 Aug 2005 10:51:54 +0200
Sender: [email-masked]

--=-=-=

I talked to Kurt Zeilenga after the meeting, and then understood what he
was talking about. The uniformResourceIdentifier part of GeneralName (and
this SubjectAltName) can be used instead of srv based names to limit what
service the certificate is allowed to serve.

Love

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

--=-=-=--

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked]
Subject: Re: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 10:50:36 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hi,

> Most QCs are probably manufactured in closed processes making
> standards less applicable.

Yes, and the reason for that is that there are no qualified certificate 
requests yet.
Having no QCSR�s makes it expensive for the manufacturing process, and 
impossible for QC creation at home.

If it is just an standardized, additional field in the CSR�s, then it should 
be easy to adopt for browser vendors, smartcard vendors and CA�s.

Overall it makes it possible to create it at home, and the manufacturing 
process will be cheaper. Vendors will produce standard "Qualified 
SmartCards". For the Browser vendors it will be a short amount of additional 
code, that I will try to offer them as easy to apply patches for their code.

Ah, good that you remind me, I haven�t worked out the PKCS#11 and CSP 
integration yet.

> For on-line generated and distributed
> certificates, practically the entire process is currently non-standard,
> beginning with browsers.

Yes, non-standard and therefore unnecessary costly.

> Few on-line certificate systems therefore 
> use the browser stuff and have introduced their own proprietary
> methods.  These methods typically also address PIN-code policies,
> something which seems to be missing in PKCS #10.  The
> OpenMobileAlliance have created additional standards but I don't think
> these have much acceptance by browser vendors.

Thanks. I�ll take a look at it.

Regards,
Philipp G�hring

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked], [email-masked]
Subject: Re: Qualified Certificate Requests - RFC
Date: Wed, 3 Aug 2005 10:46:46 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hello,

> The PEM format for OpenSSL is not standard by any means, the DER format
> is equivalent to the SubjectPublicKeyInfo format which is standard (its
> is used in certificates).

Ok, then I will try to switch to that format.

> In fact since the aim seems to be to sign one public key (which resides
> on a smart card) with another (certifying it is on a smart card) and
> possibly include additional parameters why not just do this with a
> standard certificate?

Good question, thank you!

* There is no "identity" attached to the public key, at the point of time, 
where the CSR is generated.
* I want to reuse the normal Certificate Request workflow with PKCS#11, 
browsers, and CSR�s, the <keygen> integration in the browsers and the HTTP 
based communication with the CA.
* I don�t want difficult to secure out-of-band communication (having to 
transport the raw certificate additionally to the CSR for the real 
certificate)

So I think I need an additional field in the CSR.

At the beginning of the project, I thought that it would be necessary to sign 
the whole CSR, so I would need an external signature, and could not send it 
in the normal certificate request. (Which would have meant, that I would have 
to redesign the whole communication.) 
Then I had the good idea, that a signature of only the public key would be 
enough, and that I could put the signature into the CSR itself.

I have to make sure that the generated private key is in the smartcard. Since 
the generated public key determines the private key, it is enough to sign the 
generated public key.
I also thought about a secret-key signing system, which could be 
computationally easier, but then the CA would have to keep it secret, and a 
secret key couldn�t easily be shared between several CA�s, all trusting the 
same vendor�s tokens.

Regards,
Philipp G�hring

Date: Wed, 3 Aug 2005 10:11:08 +0200 (MEST)
From: Anders Rundgren <[email-masked]>
Reply-To: Anders Rundgren <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Qualified Certificate Requests - RFC
Sender: [email-masked]

Hi,

Most QCs are probably manufactured in closed processes making 
standards less applicable.

For on-line generated and distributed 
certificates, practically the entire process is currently non-standard, 
beginning with browsers.   Few on-line certificate systems therefore 
use the browser stuff and have introduced their own proprietary 
methods.  These methods typically also address PIN-code policies, 
something which seems to be missing in PKCS #10.  The 
OpenMobileAlliance have created additional standards but I don't think 
these have much acceptance by browser vendors.

Anders Rundgren

----
Original Message----
From: [email-masked]
Date: Aug 2, 2005 10:13:55 
PM
To: [email-masked]
Subj: Qualified Certificate Requests - RFC

Hello,

I have been reading through the PKIX archive, and found a lot 
of interesting 
material on the topic of qualified certificates.

But 
what I am completely missing is the necessary foundation of qualified 
certificate requests.

Regarding the requirements for qualified 
certificates, the only obstacle I 
currently have is the problem, that 
I have to make sure, that the private key 
for the certificate is 
generated and stored securely in a SmartCard, or 
another Hardware 
Token.

Since the users should be able to issue the certificates at 
home, I need a 
technical solution to make sure, that the private key 
is from within a 
SmartCard, when we receive a certificate request.

Therefore I designed "Qualified Certificate Requests", which 
cryptographically 
signs the public key in the CSR with a vendor key, 
to state that it comes 
from a secure device.

Now I created a software-
based reference implementation, so that the security 
of the system can 
be evaluated, and that the Token Vendors can see how to do 
it, and can 
do interoperability testing:

http://www2.futureware.
at/svn/sourcerer/CAcert/QCSR/
 
The following parameters are still open 
and can be changed by the vendor: 
  The crypto algorithm (we have 
chosen RSA here)
  The encoding of the public key (we have chosen PEM 
encoding from OpenSSL) 
  The signature method (we have chosen the RSA 
signature from OpenSSL,
     which normally gives 128 binary bytes as 
signature) 
  The encoding into the qcsr field in the CSR (I have 
chosen Hex-encoding,
     since I didn�t found an easy way to do it 
directly binary yet) 
  The OID for the qcsr field (we have allocated a 
OID range below our range
     for all QCSR OID�s. Feel free to contact 
me if you want an OID for your
     parameters)

If a hardware vendor 
wants to change something on the implementation, please 
provide a 
software reference-implementation, that is bit-compatible to the 
proposed hardware implementation, so that the security can be 
evaluated. 
(I guess it will be best, if it is based on our reference-
implementation)

Should qualified certificate requests be documented in 
a own RFC, or added to 
the Qualified Certificates RFC?

Regards,
Philipp G�hring

To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: EKU ambiguity in RFC 3280
From: Sam Hartman <[email-masked]>
Date: Wed, 03 Aug 2005 03:18:08 -0400
Sender: [email-masked]

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Such applications can reject a certificate for their use if
    Russ> the expected EKU value is not present, even if the anyEKU
    Russ> OID is present.

Such applications would presumably require the EKU to be present too.

To: "Manger, James H" <[email-masked]>, <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
From: Tom Gindin <[email-masked]>
Date: Tue, 2 Aug 2005 23:16:35 -0400
Sender: [email-masked]

        James, Santosh:

        You certainly can construct unambiguous names for CA's, and I 
think that Denis already knows that (Permanent Identifier is certainly a 
way of constructing unambiguous names, for example).  The difficulty we 
have is when one issuer issues a certificate to an organizational CA with 
a subject name which is convenient and in common use for its organization, 
but ambiguous, and then a different issuer issues a certificate to an 
organizational CA with the same subject name which is also in common use 
for its organization.  This case is most common when both organizations 
use an acronym.  I do not see why the issuers of the two organizational CA 
certificates should be assumed to originate at different trust anchors, 
although they will be different issuers.  In fact, I don't understand why 
organizational name collisions are thought to be much rarer with a "common 
trust anchor" than with "different trust anchors" if the actual issuers of 
the colliding certificates are both public CA's.
        Such collisions will have negative effects in other parts of the 
global PKI, of course.  However, unless we are prepared to issue guidance 
to deprecate the assignment of DN's for organizations with geographical 
scopes wider than the one for which they are registered and guaranteed to 
be unique (and many existing CA certificates have such DN's), I don't see 
how we can be certain or nearly certain that such collisions won't occur. 
A typical example of what I mean by an organization having a DN with a 
geographical scope wider than the one for which it's registered is a 
corporation registered in a single American state and operating in several 
states while having a DN without the stateOrProvinceName attribute.

                Tom Gindin

"Manger, James H" <[email-masked]>
Sent by: [email-masked]
08/01/2005 11:05 PM
 
        To:     "pkix" <[email-masked]>
        cc: 
        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
delegated CRLs

[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the 
trust anchors environment of the relying parties to know if the CRL issuer 
DN will be unambiguous.]
You can construct unambiguous DNs regardless of trust anchors.  For 
instance, including DC components can make a DN as unambiguous as a DNS 
name.  As another example, the following DN
  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
is unambiguous as it lists a registered business name, its Australian 
Business Number (ABN) and the jurisdiction where those are unambiguous 
(Australia).  It is inconceivable that any CA could issue such a DN to 
another entity in good faith.
The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
issuing CA, but would be ambiguous in a wider context so it should not be 
used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
instance.

Content-class: urn:content-classes:message
Subject: RE: EKU: ambiguity in RFC 3280
Date: Wed, 3 Aug 2005 12:58:05 +1000
From: "Manger, James H" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C597D7.2B861EE0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C597D7.2B861EE0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C597D7.2B861EE0--

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: [email-masked]
Subject: Qualified Certificate Requests - RFC
Date: Tue, 2 Aug 2005 22:13:55 +0200
Reply-To: [email-masked]
Sender: [email-masked]

Hello,

I have been reading through the PKIX archive, and found a lot of interesting 
material on the topic of qualified certificates.

But what I am completely missing is the necessary foundation of qualified 
certificate requests.

Regarding the requirements for qualified certificates, the only obstacle I 
currently have is the problem, that I have to make sure, that the private key 
for the certificate is generated and stored securely in a SmartCard, or 
another Hardware Token.

Since the users should be able to issue the certificates at home, I need a 
technical solution to make sure, that the private key is from within a 
SmartCard, when we receive a certificate request.

Therefore I designed "Qualified Certificate Requests", which cryptographically 
signs the public key in the CSR with a vendor key, to state that it comes 
from a secure device.

Now I created a software-based reference implementation, so that the security 
of the system can be evaluated, and that the Token Vendors can see how to do 
it, and can do interoperability testing:

http://www2.futureware.at/svn/sourcerer/CAcert/QCSR/
 
The following parameters are still open and can be changed by the vendor: 
  The crypto algorithm (we have chosen RSA here)
  The encoding of the public key (we have chosen PEM encoding from OpenSSL) 
  The signature method (we have chosen the RSA signature from OpenSSL,
     which normally gives 128 binary bytes as signature) 
  The encoding into the qcsr field in the CSR (I have chosen Hex-encoding,
     since I didn�t found an easy way to do it directly binary yet) 
  The OID for the qcsr field (we have allocated a OID range below our range
     for all QCSR OID�s. Feel free to contact me if you want an OID for your
     parameters)

If a hardware vendor wants to change something on the implementation, please 
provide a software reference-implementation, that is bit-compatible to the 
proposed hardware implementation, so that the security can be evaluated. 
(I guess it will be best, if it is based on our reference-implementation)

Should qualified certificate requests be documented in a own RFC, or added to 
the Qualified Certificates RFC?

Regards,
Philipp G�hring

Date: Tue, 02 Aug 2005 13:14:12 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: EKU ambiguity in RFC 3280
Cc: [email-masked]
Sender: [email-masked]

I agree with this interpretation.  This is what is meant by:

    Certificate using applications MAY require that a particular purpose
    be indicated in order for the certificate to be acceptable to that 
application.

Such applications can reject a certificate for their use if the expected 
EKU value is not present, even if the anyEKU OID is present.

Russ

At 09:12 AM 8/2/2005, Stefan Santesson wrote:

>Are what you say that presence of anyEKU just allows an application who
>don't care about EKUs to ignore the EKU extension content?
>
>That is, that anyEKY is never considered a match when a specific EKU is
>required in a certificate?
>
>I could live with that, it just needs to be said more clearly.
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > From: Jim Schaad [mailto:[email-masked]]
> > Sent: den 2 augusti 2005 05:11
> > To: Stefan Santesson; 'pkix'
> > Subject: RE: EKU ambiguity in RFC 3280
> >
> > Stefan,
> >
> > It is my opionion that what the Kerbros working group wants is
>correct.
> > The
> > anyExtendedKeyUsage is provided so that one can place a specific EKU
>into
> > a
> > certificate, but still allow the certificate to be used for other
>usages
> > as
> > well.
> >
> > jim
> >
> > > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > > Sent: Tuesday, August 02, 2005 12:04 PM
> > > To: pkix
> > > Subject: EKU ambiguity in RFC 3280
> > >
> > >
> > >
> > > I would like to raise an issue of potential ambiguity of the
> > > specification of the EKU extension and the meaning of the anyEKU
>OID.
> > >
> > > RFC 3280 states:
> > >    If the extension is present, then the certificate MUST only be
>used
> > >    for one of the purposes indicated.  If multiple purposes are
> > >    indicated the application need not recognize all purposes
> > > indicated,
> > >    as long as the intended purpose is present.  Certificate using
> > >    applications MAY require that a particular purpose be indicated
>in
> > >    order for the certificate to be acceptable to that application.
> > >
> > >    If a CA includes extended key usages to satisfy such
>applications,
> > >    but does not wish to restrict usages of the key, the CA can
>include
> > >    the special keyPurposeID anyExtendedKeyUsage.  Conforming
> > > CAs SHOULD
> > >    NOT mark this extension as critical if the anyExtendedKeyUsage
> > >    keyPurposeID is present.
> > >
> > >
> > > The statement of concern is:
> > >    "Certificate using
> > >    applications MAY require that a particular purpose be indicated
>in
> > >    order for the certificate to be acceptable to that application."
> > >
> > >
> > > The ambiguity is whether that requirement is satisfied by
> > > presence of anyEKU in the certificate or not.
> > >
> > > On one hand you could argue that this means that an
> > > application can require that a specific EKU is explicitly
> > > listed (anyEKU would not be enough), but on the other hand
> > > you could argue that the succeeding paragraph defines the
> > > meaning of anyEKU to be equivalent to explicit presence of
> > > all possible EKUs and thus would satisfy this requirement.
> > >
> > > Compare with how we process certificate policies, where the
> > > special policy anyPolicy actually satisfies requirement for
> > > any specific policy in the path validation algorithm. That
> > > is, there is no way to specify that a particular policy must
> > > be explicitly present and that anyPolicy will not satisfy as
> > > substitution.
> > >
> > > This issue became recently highlighted in the Kerberos WG
> > > where it was suggested that the Kerberos PKINIT specification
> > > could require the Kerberos EKU to be explicitly present but
> > > would not accept the anyEKU as substitution.
> > >
> > > The practical problem arises if EKU matching is performed by
> > > a standard library which automatically match anyEKU to any
> > > specific EKU requested for the certificate. Following the
> > > logic of the Kerberos logic it would require that library to
> > > accept an argument that anyEKU matching should be disabled,
> > > which adds complexity and introduces confusion.
> > >
> > > At least I think this issue needs to be clarified in RFC 3280bis.
> > >
> > >
> > >
> >

Date: Tue, 02 Aug 2005 10:05:56 -0400
To: "Denis Pinkas" <[email-masked]>, "pkix" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: 3280bis: KeyUsage NR/CC bit
Sender: [email-masked]

[ Responding as an author of RFC 3280, not as a Security AD. ]

We have had more discussion of this bit than any other bit.  In my opinion, 
way too much.  I am quite reluctant to engage in another discussion of it.

My recollection of the last time we discussed this topic is quite 
clear.  Consensus was that the text in RFC 3280 was a good compromise and 
that any further effort have a very low probability of improving it.

Yet, the discussion happened in the ITU-T.  The result is the text in the 
message from Denis.

It seems to me that this leaves us in the same position we were in a few 
years ago.  I still do not think that the new text is providing any clarity 
over the text that is in RFC 3280.  I expect we will spend a huge amount of 
time discussing it.

The ITU-T should not have changed the name of the bit.  Several 
implementors discouraged the ITU-T from making this name change, but they 
did so anyway.  I am strongly apposed to changing the name of this bit in 
our specification, and I am very please to see that Denis is not advocating 
doing so.  I think that we should probably add a note that tells the reader 
that the ITU-T did elect to make this change.

Russ

At 06:10 AM 7/28/2005, Denis Pinkas wrote:

>Extract from: draft-ietf-pkix-rfc3280bis-01.txt :
>
>� The nonRepudiation bit is asserted when the subject public key
>is used to verify digital signatures, other than signatures on
>certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation
>service which protects against the signing entity falsely denying
>some action. In the case of later conflict, a reliable third party may
>determine the authenticity of the signed data �.
>
>I can live with the proposed ASN.1.
>
>I would however suggest to re-use some of the key words of X.509.
>In the last sentence "authenticity of the signed data" may be misleading
>since it is missing the notion of time.
>
>Proposal for a compromise with X.509 2000)/Cor.3 (04/2004):
>
>" The nonRepudiation bit is asserted when the subject public key
>is used to verify digital signatures, other than signatures on
>certificates (bit 5) and CRLs (bit 6), which are intended to signal
>that the signer is committing to the content being signed.
>In the case of later conflict, this allows to provide a non-repudiation
>service which protects against the signing entity falsely denying some 
>action �.
>
>Denis
>
>PS: The original text from the TC of X.509 is:
>
>b) contentCommitment: for verifying digital signatures which
>are intended to signal that the signer is committing to the content being 
>signed.
>The precise level of commitment, e.g. "with the intent to be bound"
>may be signaled by additional methods, e.g. certificate policy.
>
>Since a content commitment signing is considered to be a digitally signed
>transaction, the digitalSignature bit need not be set in the certificate.
>If it is set, it does not affect the level of commitment the signer has
>endowed in the signed content.
>
>Note that it is not incorrect to refer to this keyUsage bit using the
>identifier nonRepudiation. However, the use this identifier has been
>deprecated. Regardless of the identifier used, the semantics of this
>bit are as specified in this standard.

Content-class: urn:content-classes:message
Subject: RE: EKU ambiguity in RFC 3280
Date: Tue, 2 Aug 2005 14:12:18 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Jim Schaad" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

Are what you say that presence of anyEKU just allows an application who
don't care about EKUs to ignore the EKU extension content? 

That is, that anyEKY is never considered a match when a specific EKU is
required in a certificate?

I could live with that, it just needs to be said more clearly.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Jim Schaad [mailto:[email-masked]]
> Sent: den 2 augusti 2005 05:11
> To: Stefan Santesson; 'pkix'
> Subject: RE: EKU ambiguity in RFC 3280
> 
> Stefan,
> 
> It is my opionion that what the Kerbros working group wants is
correct.
> The
> anyExtendedKeyUsage is provided so that one can place a specific EKU
into
> a
> certificate, but still allow the certificate to be used for other
usages
> as
> well.
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Tuesday, August 02, 2005 12:04 PM
> > To: pkix
> > Subject: EKU ambiguity in RFC 3280
> >
> >
> >
> > I would like to raise an issue of potential ambiguity of the
> > specification of the EKU extension and the meaning of the anyEKU
OID.
> >
> > RFC 3280 states:
> >    If the extension is present, then the certificate MUST only be
used
> >    for one of the purposes indicated.  If multiple purposes are
> >    indicated the application need not recognize all purposes
> > indicated,
> >    as long as the intended purpose is present.  Certificate using
> >    applications MAY require that a particular purpose be indicated
in
> >    order for the certificate to be acceptable to that application.
> >
> >    If a CA includes extended key usages to satisfy such
applications,
> >    but does not wish to restrict usages of the key, the CA can
include
> >    the special keyPurposeID anyExtendedKeyUsage.  Conforming
> > CAs SHOULD
> >    NOT mark this extension as critical if the anyExtendedKeyUsage
> >    keyPurposeID is present.
> >
> >
> > The statement of concern is:
> >    "Certificate using
> >    applications MAY require that a particular purpose be indicated
in
> >    order for the certificate to be acceptable to that application."
> >
> >
> > The ambiguity is whether that requirement is satisfied by
> > presence of anyEKU in the certificate or not.
> >
> > On one hand you could argue that this means that an
> > application can require that a specific EKU is explicitly
> > listed (anyEKU would not be enough), but on the other hand
> > you could argue that the succeeding paragraph defines the
> > meaning of anyEKU to be equivalent to explicit presence of
> > all possible EKUs and thus would satisfy this requirement.
> >
> > Compare with how we process certificate policies, where the
> > special policy anyPolicy actually satisfies requirement for
> > any specific policy in the path validation algorithm. That
> > is, there is no way to specify that a particular policy must
> > be explicitly present and that anyPolicy will not satisfy as
> > substitution.
> >
> > This issue became recently highlighted in the Kerberos WG
> > where it was suggested that the Kerberos PKINIT specification
> > could require the Kerberos EKU to be explicitly present but
> > would not accept the anyEKU as substitution.
> >
> > The practical problem arises if EKU matching is performed by
> > a standard library which automatically match anyEKU to any
> > specific EKU requested for the certificate. Following the
> > logic of the Kerberos logic it would require that library to
> > accept an argument that anyEKU matching should be disabled,
> > which adds complexity and introduces confusion.
> >
> > At least I think this issue needs to be clarified in RFC 3280bis.
> >
> >
> >
> 

From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'pkix'" <[email-masked]>
Subject: RE: EKU ambiguity in RFC 3280
Date: Tue, 2 Aug 2005 14:10:53 +0200
Sender: [email-masked]

Stefan,

It is my opionion that what the Kerbros working group wants is correct.  The
anyExtendedKeyUsage is provided so that one can place a specific EKU into a
certificate, but still allow the certificate to be used for other usages as
well.

jim 

> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Tuesday, August 02, 2005 12:04 PM
> To: pkix
> Subject: EKU ambiguity in RFC 3280
> 
> 
> 
> I would like to raise an issue of potential ambiguity of the 
> specification of the EKU extension and the meaning of the anyEKU OID.
> 
> RFC 3280 states:
>    If the extension is present, then the certificate MUST only be used
>    for one of the purposes indicated.  If multiple purposes are
>    indicated the application need not recognize all purposes 
> indicated,
>    as long as the intended purpose is present.  Certificate using
>    applications MAY require that a particular purpose be indicated in
>    order for the certificate to be acceptable to that application.
> 
>    If a CA includes extended key usages to satisfy such applications,
>    but does not wish to restrict usages of the key, the CA can include
>    the special keyPurposeID anyExtendedKeyUsage.  Conforming 
> CAs SHOULD
>    NOT mark this extension as critical if the anyExtendedKeyUsage
>    keyPurposeID is present.
> 
> 
> The statement of concern is:
>    "Certificate using
>    applications MAY require that a particular purpose be indicated in
>    order for the certificate to be acceptable to that application."
> 
> 
> The ambiguity is whether that requirement is satisfied by 
> presence of anyEKU in the certificate or not.
> 
> On one hand you could argue that this means that an 
> application can require that a specific EKU is explicitly 
> listed (anyEKU would not be enough), but on the other hand 
> you could argue that the succeeding paragraph defines the 
> meaning of anyEKU to be equivalent to explicit presence of 
> all possible EKUs and thus would satisfy this requirement.
> 
> Compare with how we process certificate policies, where the 
> special policy anyPolicy actually satisfies requirement for 
> any specific policy in the path validation algorithm. That 
> is, there is no way to specify that a particular policy must 
> be explicitly present and that anyPolicy will not satisfy as 
> substitution.
> 
> This issue became recently highlighted in the Kerberos WG 
> where it was suggested that the Kerberos PKINIT specification 
> could require the Kerberos EKU to be explicitly present but 
> would not accept the anyEKU as substitution.
> 
> The practical problem arises if EKU matching is performed by 
> a standard library which automatically match anyEKU to any 
> specific EKU requested for the certificate. Following the 
> logic of the Kerberos logic it would require that library to 
> accept an argument that anyEKU matching should be disabled, 
> which adds complexity and introduces confusion.
> 
> At least I think this issue needs to be clarified in RFC 3280bis.
> 
> 
> 

Content-class: urn:content-classes:message
Subject: EKU ambiguity in RFC 3280
Date: Tue, 2 Aug 2005 11:04:16 +0100
From: "Stefan Santesson" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

I would like to raise an issue of potential ambiguity of the
specification of the EKU extension and the meaning of the anyEKU OID.

RFC 3280 states:
   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.  If multiple purposes are
   indicated the application need not recognize all purposes indicated,
   as long as the intended purpose is present.  Certificate using
   applications MAY require that a particular purpose be indicated in
   order for the certificate to be acceptable to that application.

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special keyPurposeID anyExtendedKeyUsage.  Conforming CAs SHOULD
   NOT mark this extension as critical if the anyExtendedKeyUsage
   keyPurposeID is present.

The statement of concern is:
   "Certificate using
   applications MAY require that a particular purpose be indicated in
   order for the certificate to be acceptable to that application."

The ambiguity is whether that requirement is satisfied by presence of
anyEKU in the certificate or not.

On one hand you could argue that this means that an application can
require that a specific EKU is explicitly listed (anyEKU would not be
enough), but on the other hand you could argue that the succeeding
paragraph defines the meaning of anyEKU to be equivalent to explicit
presence of all possible EKUs and thus would satisfy this requirement.

Compare with how we process certificate policies, where the special
policy anyPolicy actually satisfies requirement for any specific policy
in the path validation algorithm. That is, there is no way to specify
that a particular policy must be explicitly present and that anyPolicy
will not satisfy as substitution.

This issue became recently highlighted in the Kerberos WG where it was
suggested that the Kerberos PKINIT specification could require the
Kerberos EKU to be explicitly present but would not accept the anyEKU as
substitution.

The practical problem arises if EKU matching is performed by a standard
library which automatically match anyEKU to any specific EKU requested
for the certificate. Following the logic of the Kerberos logic it would
require that library to accept an argument that anyEKU matching should
be disabled, which adds complexity and introduces confusion.

At least I think this issue needs to be clarified in RFC 3280bis.

Content-class: urn:content-classes:message
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Tue, 2 Aug 2005 13:05:18 +1000
From: "Manger, James H" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5970F.0318AEA0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C5970F.0318AEA0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C5970F.0318AEA0--

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 1 Aug 2005 13:35:26 -0400
Importance: Normal
Sender: [email-masked]

David,

I stand corrected.

For what it is worth, X.509 does not seem to have rules for matching issuer
alt name.

Given the syntax of CRL issuer field in CRL DP (General Names), it is
logical that non-DN names will be matched with the issuer alt name.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Monday, August 01, 2005 12:26 PM
Cc: pkix
Subject: Re: 3280bis: suggested words for ambiguous DNs and delegated CRLs

Santosh,

Actually, the standard DOES require that the name in the cRLIssuer field 
match one of the names in the issuer field of issuerAltName extension of 
the CRL.

In RFC 3280 (and 3280bis), section 6.3.3 step (b)(1) states:

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

It is true that according to section 6.3.3 step (b)(2), if the CRL 
contains an IDP extension with a distribution point name and the 
distribution point in the CDP extension of the certificate includes a 
cRLIssuer field but does not include a distribution point name, then the 
contents of the cRLIssuer field can be compared to the distribution 
point name in the IDP extension in the CRL.  However, this does not 
eliminate the requirement from step (b)(1) to for the issuer field (or 
issuerAltName extension) in the CRL to include a name that matches the 
contents of the cRLIssuer field in the CDP extension.

Dave

Santosh Chokhani wrote:

>[mailto:[email-masked]] On Behalf Of Manger, James H
>Sent: Monday, August 01, 2005 3:34 AM
>To: pkix
>Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>Replace the last text paragraph in 4.2.1.13 with the following: "The 
>cRLIssuer field identifies the entity who signs and issues the CRL. Any 
>CRL it selects must include at least one of the names from cRLIssuer in 
>the CRL's issuer field or issuerAltName extension.
>
>[Santosh: This is not a requirement of the standard today.  The 
>standard permits the CRL issuer name to be matched to a DP in the IDP.  
>In retrospect, the standard should have matched CRL issuer from CRL DP 
>to issuer field or issuer alt name field in the CRL and matched DPs 
>from CRL DP and IDP.  That would have been a more appropriate 
>solution.]
>

Date: Mon, 01 Aug 2005 12:42:20 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Sender: [email-masked]

Manger, James H wrote:

>Change 4.2.1.13 "CRL Distribution Points" to allow non-DN names in the cRLIssuer field and to avoid this field when the CRL issuer only works for one CA.  With any luck this could solve the "ambiguous DN in CRL processing" issue, as well as Denis’s "simplified processing for 'delegated CRLs'".  Replace the last text paragraph in 4.2.1.13 with the following:
>
>
>"The cRLIssuer field identifies the entity who signs and issues the CRL.  Any CRL it selects must include at least one of the names from cRLIssuer in the CRL’s issuer field or issuerAltName extension.  The CRL MUST also include an issuingDistributionPoint extension with indirectCRL set to TRUE.
>
>A CRL issuer SHOULD use the same DN as the CA if it will only ever cover certificates from that single CA.  This avoids the need for cRLIssuer values in certificates and, more importantly, avoids the need for the indirectCRL flag and certificateIssuer values in critical extensions in CRLs.  A separate name for the CRL issuer can still be included in a CRL via the issuerAltName extension if desired.
>  
>
I think we need to be careful about saying that this method "SHOULD" be 
used.  While it is interesting to note that one can delegate CRL issuing 
to a different system without the use of indirect CRLs, it may not be 
considered appropriate for the CRL issuer to use the same name as the 
certificate issuer if the two systems are being run by different 
organizations.  Even if there is a decision to point out in 3280bis that 
it is possible to delegate the issuance to CRLs to a different system 
without using indirect CRLs, I think such guidance should go in section 
5 rather than section 4.2.1.13.

>It is important that the cRLIssuer field in a certificate unambiguously identifies a single CRL issuer.  A CA MUST only include names in the cRLIssuer field that are unambiguous within the environment where the certificate may be used, which will often mean cRLIssuer names MUST be globally unambiguous.  A globally unambiguous name, such as a DNS name, MUST be used in cRLIssuer when the CRL issuer’s DN is ambiguous."
>  
>
I have a problem with this paragraph since X.509 requires that ALL names 
be unambiguous.  Including language such as this implies that it is OK 
to use ambiguous names expect in cases such as this.  If a CA or CRL 
issuer can have a DNS name that is globally unambiguous, then it can 
certainly use domainComponent naming to construct a DN is that unambiguous.

Dave

Date: Mon, 01 Aug 2005 12:25:45 -0400
From: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Sender: [email-masked]

Santosh,

Actually, the standard DOES require that the name in the cRLIssuer field 
match one of the names in the issuer field of issuerAltName extension of 
the CRL.

In RFC 3280 (and 3280bis), section 6.3.3 step (b)(1) states:

         (1)  If the DP includes cRLIssuer, then verify that the issuer
         field in the complete CRL matches cRLIssuer in the DP and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted.  Otherwise,
         verify that the CRL issuer matches the certificate issuer.

It is true that according to section 6.3.3 step (b)(2), if the CRL 
contains an IDP extension with a distribution point name and the 
distribution point in the CDP extension of the certificate includes a 
cRLIssuer field but does not include a distribution point name, then the 
contents of the cRLIssuer field can be compared to the distribution 
point name in the IDP extension in the CRL.  However, this does not 
eliminate the requirement from step (b)(1) to for the issuer field (or 
issuerAltName extension) in the CRL to include a name that matches the 
contents of the cRLIssuer field in the CDP extension.

Dave

Santosh Chokhani wrote:

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Manger, James H
>Sent: Monday, August 01, 2005 3:34 AM
>To: pkix
>Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>
>
>Replace the last text paragraph in 4.2.1.13 with the following:
>"The cRLIssuer field identifies the entity who signs and issues the CRL.
>Any CRL it selects must include at least one of the names from cRLIssuer in
>the CRL's issuer field or issuerAltName extension.
>
>[Santosh: This is not a requirement of the standard today.  The standard
>permits the CRL issuer name to be matched to a DP in the IDP.  In
>retrospect, the standard should have matched CRL issuer from CRL DP to
>issuer field or issuer alt name field in the CRL and matched DPs from CRL DP
>and IDP.  That would have been a more appropriate solution.]
>

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 1 Aug 2005 10:47:29 -0400
Importance: Normal
Sender: [email-masked]

James Manger,

See responses in-line under [Santosh:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manger, James H
Sent: Monday, August 01, 2005 3:34 AM
To: pkix
Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs

Change 4.2.1.13 "CRL Distribution Points" to allow non-DN names in the
cRLIssuer field and to avoid this field when the CRL issuer only works for
one CA.

[Santosh: The syntax has always allowed non-DN names.  In terms of avoiding
this field, the standard requires that if the Issuer field in the CRL is not
the same as the Issuer field in the certificate, the certificate issuing CA
assert the CRL Issuer in the CRL DP.  Not doing this can lead to any one
acting as a revocation authority for a CA and that would be bad.]

With any luck this could solve the "ambiguous DN in CRL processing" issue,
as well as Denis's "simplified processing for 'delegated CRLs'".

[Santosh: Having multiple names in the CRL issuer field of CRL DP and
checking them all might reduce the chances of name collision, if that is
what you mean.]

Replace the last text paragraph in 4.2.1.13 with the following:
"The cRLIssuer field identifies the entity who signs and issues the CRL.
Any CRL it selects must include at least one of the names from cRLIssuer in
the CRL's issuer field or issuerAltName extension.

[Santosh: This is not a requirement of the standard today.  The standard
permits the CRL issuer name to be matched to a DP in the IDP.  In
retrospect, the standard should have matched CRL issuer from CRL DP to
issuer field or issuer alt name field in the CRL and matched DPs from CRL DP
and IDP.  That would have been a more appropriate solution.]

The CRL MUST also include an issuingDistributionPoint extension with
indirectCRL set to TRUE.

A CRL issuer SHOULD use the same DN as the CA if it will only ever cover
certificates from that single CA.

[Santosh: This by definition is not an indirect CRL.  This is the case where
the CA is using a different key to sign the CRL.]

This avoids the need for cRLIssuer values in certificates and, more
importantly, avoids the need for the indirectCRL flag and certificateIssuer
values in critical extensions in CRLs.  A separate name for the CRL issuer
can still be included in a CRL via the issuerAltName extension if desired.

[Santosh: While I can support a change in the standard to match CRL issuer
in CRL DP to issuer or issuer alt name in CRL and match the DPs, I do not
want another authority to assert the issuer field in a name and assert its
name in the alt name.]

It is important that the cRLIssuer field in a certificate unambiguously
identifies a single CRL issuer.  A CA MUST only include names in the
cRLIssuer field that are unambiguous within the environment where the
certificate may be used, which will often mean cRLIssuer names MUST be
globally unambiguous.  A globally unambiguous name, such as a DNS name, MUST
be used in cRLIssuer when the CRL issuer's DN is ambiguous."

[Santosh: Requiring a unique DNS may be fine.  But, CA does not know the
trust anchors environment of the relying parties to know if the CRL issuer
DN will be unambiguous.]

(There are probably some parts of the CRL processing text that need to
change to match this text.)

Content-class: urn:content-classes:message
Subject: 3280bis: suggested words for ambiguous DNs and delegated CRLs
Date: Mon, 1 Aug 2005 17:34:07 +1000
From: "Manger, James H" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

Change 4.2.1.13 "CRL Distribution Points" to allow non-DN names in the cRLIssuer field and to avoid this field when the CRL issuer only works for one CA.  With any luck this could solve the "ambiguous DN in CRL processing" issue, as well as Denis’s "simplified processing for 'delegated CRLs'".  Replace the last text paragraph in 4.2.1.13 with the following:

"The cRLIssuer field identifies the entity who signs and issues the CRL.  Any CRL it selects must include at least one of the names from cRLIssuer in the CRL’s issuer field or issuerAltName extension.  The CRL MUST also include an issuingDistributionPoint extension with indirectCRL set to TRUE.

A CRL issuer SHOULD use the same DN as the CA if it will only ever cover certificates from that single CA.  This avoids the need for cRLIssuer values in certificates and, more importantly, avoids the need for the indirectCRL flag and certificateIssuer values in critical extensions in CRLs.  A separate name for the CRL issuer can still be included in a CRL via the issuerAltName extension if desired.

It is important that the cRLIssuer field in a certificate unambiguously identifies a single CRL issuer.  A CA MUST only include names in the cRLIssuer field that are unambiguous within the environment where the certificate may be used, which will often mean cRLIssuer names MUST be globally unambiguous.  A globally unambiguous name, such as a DNS name, MUST be used in cRLIssuer when the CRL issuer’s DN is ambiguous."

(There are probably some parts of the CRL processing text that need to change to match this text.)