From nobody Tue Apr 1 01:51:06 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76C1A702A for ; Tue, 1 Apr 2014 01:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.81 X-Spam-Level: * X-Spam-Status: No, score=1.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-NIr4JLLdur for ; Tue, 1 Apr 2014 01:51:03 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1C1A6FFB for ; Tue, 1 Apr 2014 01:51:02 -0700 (PDT) Received: from ([62.44.135.107]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id NMZ91755 for ; Tue, 01 Apr 2014 10:50:55 +0200 From: "Erik Andersen" To: "PKIX" Date: Tue, 1 Apr 2014 10:50:52 +0200 Message-ID: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CF4D98.42E5FC10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac9Nhq/XO8TxjiSfR0mH3ggMueSNqQ== Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/_lZmBwSYAcadm7KBn_zG-0Xn4f8 Subject: [pkix] OCSP - revoked stte for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 08:51:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01CF4D98.42E5FC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folk, In the last paragraph of section 5 of RFC 6960, it is mentioned a possible threat when the status "revoked" is issued for a certificate alter to be issued. How can an attacker utilize this situation? The answer is probably buried somewhere in the hundreds of emails on 2560bis. Erik ------=_NextPart_000_000F_01CF4D98.42E5FC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folk,

 

In the last paragraph of section 5 of RFC 6960, it is = mentioned a possible threat when  the status ”revoked” = is issued for a certificate alter to be issued.

 

How can an = attacker utilize this situation?

 

The answer = is probably buried somewhere in the hundreds of emails on = 2560bis.

 

Erik

------=_NextPart_000_000F_01CF4D98.42E5FC10-- From nobody Tue Apr 1 03:02:24 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA7D1A0844 for ; Tue, 1 Apr 2014 03:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6c7pnJwHRwq for ; Tue, 1 Apr 2014 03:02:21 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) by ietfa.amsl.com (Postfix) with ESMTP id B47781A7D85 for ; Tue, 1 Apr 2014 03:02:18 -0700 (PDT) Received: from [192.168.0.12] (unknown [88.182.125.39]) by smtp2-g21.free.fr (Postfix) with ESMTP id 44C074B010C for ; Tue, 1 Apr 2014 12:02:09 +0200 (CEST) Message-ID: <533A8EA8.2080007@free.fr> Date: Tue, 01 Apr 2014 12:02:16 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> In-Reply-To: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> Content-Type: multipart/alternative; boundary="------------080101000608000705000705" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/6q-jLNPcMGPhLXDakqZqoJGQ-g8 Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 10:02:22 -0000 This is a multi-part message in MIME format. --------------080101000608000705000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Erik RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is not the case. I still consider RFC 2560 (which unclear on many points) better than RFC 6960, since it added text that is incompatible with the documents from the CAB (CA Browser Forum). Would you be able to quote the sentence that you don't fully understand ? Denis > Hi Folk, > > In the last paragraph of section 5 of RFC 6960, it is mentioned a > possible threat when the status "revoked" is issued for a certificate > alter to be issued. > > How can an attacker utilize this situation? > > The answer is probably buried somewhere in the hundreds of emails on > 2560bis. > > Erik > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------080101000608000705000705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Erik

RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is not the case.
I still consider RFC 2560 (which unclear on many points) better than RFC 6960, since it added text
that is incompatible with the documents from the CAB (CA Browser Forum).

Would you be able to quote the sentence that you don't fully understand ?

Denis

Hi Folk,

 

In the last paragraph of section 5 of RFC 6960, it is mentioned a possible threat when  the status ”revoked” is issued for a certificate alter to be issued.

 

How can an attacker utilize this situation?

 

The answer is probably buried somewhere in the hundreds of emails on 2560bis.

 

Erik



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------080101000608000705000705-- From nobody Tue Apr 1 03:51:37 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687CD1A86E0 for ; Tue, 1 Apr 2014 03:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zs5fsUCGxWe for ; Tue, 1 Apr 2014 03:51:34 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD771A86DD for ; Tue, 1 Apr 2014 03:51:33 -0700 (PDT) Received: from ([62.44.135.107]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id NOA97125 for ; Tue, 01 Apr 2014 12:51:25 +0200 From: "Erik Andersen" To: References: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> <533A8EA8.2080007@free.fr> In-Reply-To: <533A8EA8.2080007@free.fr> Date: Tue, 1 Apr 2014 12:51:23 +0200 Message-ID: <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01CF4DA9.1861D430" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJrBMbLtmGj4Pm6iAQDUciTLtjVmAIrPh3BmbPKUgA= Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/qLhfRywb99Tsx3I4Vfm5JkFIP0s Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 10:51:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0029_01CF4DA9.1861D430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Denis, Did you change your email address? The start of the last paragraph of section 5 says: Responding with a "revoked" state to a certificate that has never been issued may enable someone to obtain a revocation response for a certificate that is not yet issued, but soon will be issued, if the certificate serial number of the certificate that will be issued can be predicted or guessed by the requestor. So, assume I am bad guy. I have gotten hold of a OCSP response saying "revoked" for certificate about to be issued. How can I use that response to do nasty things? Regards, Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Tuesday, April 01, 2014 12:02 PM To: pkix@ietf.org Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates Hi Erik RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is not the case. I still consider RFC 2560 (which unclear on many points) better than RFC 6960, since it added text that is incompatible with the documents from the CAB (CA Browser Forum). Would you be able to quote the sentence that you don't fully understand ? Denis Hi Folk, In the last paragraph of section 5 of RFC 6960, it is mentioned a possible threat when the status "revoked" is issued for a certificate alter to be issued. How can an attacker utilize this situation? The answer is probably buried somewhere in the hundreds of emails on 2560bis. Erik _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0029_01CF4DA9.1861D430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

Did you change your = email address?

 

The start of the last = paragraph of section 5 says:

 

Responding with a "revoked" state to a = certificate that has never

been issued may enable someone to obtain a = revocation response for a

certificate that is not yet issued, but soon will be = issued, if the

certificate serial number of the certificate that = will be issued can

be predicted or guessed by the = requestor.

 

So, assume I = am  bad guy. I have gotten hold of a OCSP response saying = “revoked” for  certificate about to be issued. How can = I use that response to do nasty things?

 

Regards,

 

Erik

 

From: pkix = [mailto:pkix-bounces@ietf.org] On Behalf Of Denis
Sent: = Tuesday, April 01, 2014 12:02 PM
To: = pkix@ietf.org
Subject: Re: [pkix] OCSP - revoked stte for = non-issued certificates

 

Hi Erik

RFC 6960 was supposed to = be better than RFC 2560. Unfortunately this is not the case.
I still = consider RFC 2560 (which unclear on many points) better than RFC 6960, = since it added text
that is incompatible with the documents from the = CAB (CA Browser Forum).

Would you be able to quote the sentence = that you don't fully understand ?

Denis<= /p>

Hi Folk,

 

In the last paragraph of section 5 of RFC 6960, it is = mentioned a possible threat when  the status ”revoked” = is issued for a certificate alter to be issued.

 

How can an = attacker utilize this situation?

 

The answer = is probably buried somewhere in the hundreds of emails on = 2560bis.

 

Erik




=

_______________________________________________
=
pkix mailing list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix

 

------=_NextPart_000_0029_01CF4DA9.1861D430-- From nobody Tue Apr 1 05:37:53 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB11A06B7 for ; Tue, 1 Apr 2014 05:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9qN9YhArr-E for ; Tue, 1 Apr 2014 05:37:47 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F61A06AD for ; Tue, 1 Apr 2014 05:37:45 -0700 (PDT) Received: from [192.168.0.12] (unknown [88.182.125.39]) by smtp4-g21.free.fr (Postfix) with ESMTP id 5D0F64C8081 for ; Tue, 1 Apr 2014 14:37:36 +0200 (CEST) Message-ID: <533AB317.7030000@free.fr> Date: Tue, 01 Apr 2014 14:37:43 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> <533A8EA8.2080007@free.fr> <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> In-Reply-To: <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> Content-Type: multipart/alternative; boundary="------------070701040100010703040404" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/9Ez3iEFwEQmhsMsNolN0KKKqfxE Subject: Re: [pkix] OCSP - revoked state for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:37:51 -0000 This is a multi-part message in MIME format. --------------070701040100010703040404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Erik, I have some difficulties to think that you might be a bad guy ... so you will play the role of the good guy. Suppose that you (as an honest client), don't use the nonce extension and that the OCSP server uses pre-computed responses. Let us suppose that OCSP responses are valid for 12 hours. Some one else (the bad guy) has guessed in advance the serial number of a certificate that will be issued. He makes an OCSP request and gets back a revoked status. The OCSP server places that response in a cache, in case someone else would make the same request. It happens that you are that "some one else". It is likely that you might get that cached pre-computed response, since the text is silent about the way cached responses and pre-computed responses are managed. Rather than getting a good status, you will get a revoked status. Some one else could say that the third paragraph from the same section addresses the concern. Let us first quote that paragraph: The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution. The text comes from RFC 2560 and has not been updated. The case described above is the replay of an old (revoked) response, which is not addressed in the paragraph quoted above, since it only addresses the case of an old (good) response. Erik, you are right to notice that the security considerations section is missing to provide sufficient guidance. Denis > Hi Denis, > > Did you change your email address? > > The start of the last paragraph of section 5 says: > > Responding with a "revoked" state to a certificate that has never > > been issued may enable someone to obtain a revocation response for a > > certificate that is not yet issued, but soon will be issued, if the > > certificate serial number of the certificate that will be issued can > > be predicted or guessed by the requestor. > > So, assume I am bad guy. I have gotten hold of a OCSP response saying > "revoked" for certificate about to be issued. How can I use that > response to do nasty things? > > Regards, > > Erik > > *From:*pkix [mailto:pkix-bounces@ietf.org] *On Behalf Of *Denis > *Sent:* Tuesday, April 01, 2014 12:02 PM > *To:* pkix@ietf.org > *Subject:* Re: [pkix] OCSP - revoked stte for non-issued certificates > > Hi Erik > > RFC 6960 was supposed to be better than RFC 2560. Unfortunately this > is not the case. > I still consider RFC 2560 (which unclear on many points) better than > RFC 6960, since it added text > that is incompatible with the documents from the CAB (CA Browser Forum). > > Would you be able to quote the sentence that you don't fully understand ? > > Denis > > Hi Folk, > > In the last paragraph of section 5 of RFC 6960, it is mentioned a > possible threat when the status "revoked" is issued for a > certificate alter to be issued. > > How can an attacker utilize this situation? > > The answer is probably buried somewhere in the hundreds of emails > on 2560bis. > > Erik > > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------070701040100010703040404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Erik,

I have some difficulties to think that you might be a bad guy ... so you will play the role of the good guy.

Suppose that you (as an honest client), don't use the nonce extension and that the OCSP server uses
pre-computed responses. Let us suppose that OCSP responses are valid for 12 hours.

Some one else (the bad guy) has guessed in advance the serial number of a certificate that will be issued.
He makes an OCSP request and gets back a revoked status. The OCSP server places that response in a cache,
in case someone else would make the same request. It happens that you are that "some one else".

It is likely that you might get that cached pre-computed response, since the text is silent about the way
cached responses and pre-computed responses are managed.

Rather than getting a good status, you will get a revoked status.

Some one else could say that the third paragraph from the same section addresses the concern.

Let us first quote that paragraph:

   The use of precomputed responses allows replay attacks in which an
   old (good) response is replayed prior to its expiration date but
   after the certificate has been revoked.  Deployments of OCSP should
   carefully evaluate the benefit of precomputed responses against the
   probability of a replay attack and the costs associated with its
   successful execution.

The text comes from RFC 2560 and has not been updated.

The case described above is the replay of an old (revoked) response, which is not addressed
in the paragraph quoted above, since it only addresses the case of an old (good) response.

Erik, you are right to notice that the security considerations section is missing to provide sufficient guidance.

Denis

Hi Denis,

 

Did you change your email address?

 

The start of the last paragraph of section 5 says:

 

Responding with a "revoked" state to a certificate that has never

been issued may enable someone to obtain a revocation response for a

certificate that is not yet issued, but soon will be issued, if the

certificate serial number of the certificate that will be issued can

be predicted or guessed by the requestor.

 

So, assume I am  bad guy. I have gotten hold of a OCSP response saying “revoked” for  certificate about to be issued. How can I use that response to do nasty things?

 

Regards,

 

Erik

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis
Sent: Tuesday, April 01, 2014 12:02 PM
To: pkix@ietf.org
Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates

 

Hi Erik

RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is not the case.
I still consider RFC 2560 (which unclear on many points) better than RFC 6960, since it added text
that is incompatible with the documents from the CAB (CA Browser Forum).

Would you be able to quote the sentence that you don't fully understand ?

Denis

Hi Folk,

 

In the last paragraph of section 5 of RFC 6960, it is mentioned a possible threat when  the status ”revoked” is issued for a certificate alter to be issued.

 

How can an attacker utilize this situation?

 

The answer is probably buried somewhere in the hundreds of emails on 2560bis.

 

Erik




_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

 



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------070701040100010703040404-- From nobody Tue Apr 1 05:46:22 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763E01A06C5 for ; Tue, 1 Apr 2014 05:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7TDJyl3iBgc for ; Tue, 1 Apr 2014 05:46:16 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id A599A1A06BE for ; Tue, 1 Apr 2014 05:46:15 -0700 (PDT) Received: from ([62.44.135.107]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id NQV77708 for ; Tue, 01 Apr 2014 14:46:08 +0200 From: "Erik Andersen" To: References: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> <533A8EA8.2080007@free.fr> <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> <533AB317.7030000@free.fr> In-Reply-To: <533AB317.7030000@free.fr> Date: Tue, 1 Apr 2014 14:46:05 +0200 Message-ID: <004201cf4da8$5b3ea3b0$11bbeb10$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01CF4DB9.1ECC0790" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJrBMbLtmGj4Pm6iAQDUciTLtjVmAIrPh3BAitnaK0DQWYlgpmIhiqw Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/U_jjA-95b5jhpVRnkFv2-weRPks Subject: Re: [pkix] OCSP - revoked state for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:46:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0043_01CF4DB9.1ECC0790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Denis, Thanks for your response. It was useful. It looks like an additional reason for using non-sequential sequence numbers. Regards, Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Tuesday, April 01, 2014 2:38 PM To: pkix@ietf.org Subject: Re: [pkix] OCSP - revoked state for non-issued certificates Hi Erik, I have some difficulties to think that you might be a bad guy ... so you will play the role of the good guy. Suppose that you (as an honest client), don't use the nonce extension and that the OCSP server uses pre-computed responses. Let us suppose that OCSP responses are valid for 12 hours. Some one else (the bad guy) has guessed in advance the serial number of a certificate that will be issued. He makes an OCSP request and gets back a revoked status. The OCSP server places that response in a cache, in case someone else would make the same request. It happens that you are that "some one else". It is likely that you might get that cached pre-computed response, since the text is silent about the way cached responses and pre-computed responses are managed. Rather than getting a good status, you will get a revoked status. Some one else could say that the third paragraph from the same section addresses the concern. Let us first quote that paragraph: The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution. The text comes from RFC 2560 and has not been updated. The case described above is the replay of an old (revoked) response, which is not addressed in the paragraph quoted above, since it only addresses the case of an old (good) response. Erik, you are right to notice that the security considerations section is missing to provide sufficient guidance. Denis Hi Denis, Did you change your email address? The start of the last paragraph of section 5 says: Responding with a "revoked" state to a certificate that has never been issued may enable someone to obtain a revocation response for a certificate that is not yet issued, but soon will be issued, if the certificate serial number of the certificate that will be issued can be predicted or guessed by the requestor. So, assume I am bad guy. I have gotten hold of a OCSP response saying "revoked" for certificate about to be issued. How can I use that response to do nasty things? Regards, Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Tuesday, April 01, 2014 12:02 PM To: pkix@ietf.org Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates Hi Erik RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is not the case. I still consider RFC 2560 (which unclear on many points) better than RFC 6960, since it added text that is incompatible with the documents from the CAB (CA Browser Forum). Would you be able to quote the sentence that you don't fully understand ? Denis Hi Folk, In the last paragraph of section 5 of RFC 6960, it is mentioned a possible threat when the status "revoked" is issued for a certificate alter to be issued. How can an attacker utilize this situation? The answer is probably buried somewhere in the hundreds of emails on 2560bis. Erik _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0043_01CF4DB9.1ECC0790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

Thanks for your = response. It was useful.

 

It looks like an = additional reason for using non-sequential sequence = numbers.

 

Regards,

 

Erik

 

From: pkix = [mailto:pkix-bounces@ietf.org] On Behalf Of Denis
Sent: = Tuesday, April 01, 2014 2:38 PM
To: pkix@ietf.org
Subje= ct: Re: [pkix] OCSP - revoked state for non-issued = certificates

 

Hi Erik,

I have some difficulties = to think that you might be a bad guy ... so you will play the role of = the good guy.

Suppose that you (as an honest client), don't use = the nonce extension and that the OCSP server uses
pre-computed = responses. Let us suppose that OCSP responses are valid for 12 = hours.

Some one else (the bad guy) has guessed in advance the = serial number of a certificate that will be issued.
He makes an OCSP = request and gets back a revoked status. The OCSP server places that = response in a cache,
in case someone else would make the same = request. It happens that you are that "some one else". =

It is likely that you might get that cached pre-computed = response, since the text is silent about the way
cached responses = and pre-computed responses are managed.

Rather than getting a = good status, you will get a revoked status.

Some one else could = say that the third paragraph from the same section addresses the = concern.

Let us first quote that paragraph:

   = The use of precomputed responses allows replay attacks in which = an
   old (good) = response is replayed prior to its expiration date but
   = after the certificate has been revoked.  Deployments of OCSP = should
   carefully evaluate the benefit of precomputed = responses against the
   probability of a replay attack and = the costs associated with its
   successful = execution.

The text comes from RFC 2560 and has not been = updated.

The case described above is the replay of an old (revoked) response, which is not = addressed
in the paragraph quoted above, since it only addresses the = case of an old (good) = response.

Erik, you are right to notice that the security = considerations section is missing to provide sufficient = guidance.

Denis<= /p>

Hi = Denis,

 

Did you change your = email address?

 

The start of the last = paragraph of section 5 says:

 

Responding with a "revoked" state to a = certificate that has never

been issued may enable someone to obtain a = revocation response for a

certificate that is not yet issued, but soon will be = issued, if the

certificate serial number of the certificate that = will be issued can

be predicted or guessed by the = requestor.

 

So, assume I = am  bad guy. I have gotten hold of a OCSP response saying = “revoked” for  certificate about to be issued. How can = I use that response to do nasty things?

 

Regards,

 

Erik

 

From: pkix = [mailto:pkix-bounces@ietf.org] = On Behalf Of Denis
Sent: Tuesday, April 01, 2014 12:02 = PM
To: pkix@ietf.org
Subject: Re: = [pkix] OCSP - revoked stte for non-issued = certificates

 

Hi Erik

RFC 6960 was supposed to = be better than RFC 2560. Unfortunately this is not the case.
I still = consider RFC 2560 (which unclear on many points) better than RFC 6960, = since it added text
that is incompatible with the documents from the = CAB (CA Browser Forum).

Would you be able to quote the sentence = that you don't fully understand = ?

Denis

Hi Folk,

 

In the last paragraph of section 5 of RFC 6960, it is = mentioned a possible threat when  the status ”revoked” = is issued for a certificate alter to be issued.

 

How can an = attacker utilize this situation?

 

The answer = is probably buried somewhere in the hundreds of emails on = 2560bis.

 

Erik





___=
____________________________________________
pkix =
mailing list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix

 




=

_______________________________________________
=
pkix mailing list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix

 

------=_NextPart_000_0043_01CF4DB9.1ECC0790-- From nobody Tue Apr 1 06:50:05 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F01A070F for ; Tue, 1 Apr 2014 06:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR8tw9bUBBpl for ; Tue, 1 Apr 2014 06:50:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C01A06BE for ; Tue, 1 Apr 2014 06:50:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1BE501F03C0; Tue, 1 Apr 2014 09:49:57 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 01D141F0529; Tue, 1 Apr 2014 09:49:57 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 1 Apr 2014 09:49:56 -0400 From: "Miller, Timothy J." To: 'Erik Andersen' , "pkix@ietf.org" Thread-Topic: [pkix] OCSP - revoked stte for non-issued certificates Thread-Index: Ac9Nhq/XO8TxjiSfR0mH3ggMueSNqQALE0UAAAG3I4AAAlmNMA== Date: Tue, 1 Apr 2014 13:49:56 +0000 Message-ID: <195DB2510AAA004391F58E28FCE2120046156CCD@IMCMBX01.MITRE.ORG> References: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> <533A8EA8.2080007@free.fr> <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> In-Reply-To: <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/d1ihN2YGkJ8j4GyJ_5dx3kVORYE Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 13:50:04 -0000 An attacker with the ability to replay OCSP responses to a victim can colle= ct "revoked" responses (assuming no nonce) for not-yet-issued serial number= s and then replay them to a victim after those certificates are issued caus= ing the victim to reject those certificates. =20 At the lowest impact, this is simply disruptive. =20 At medium impacts, it could be used as a DoS against the PKI or Subscribers= . =20 At worst I could conceivably use this as part of a key rollover attack, whe= re I convince the victim that the legitimate certificate is revoked and ope= n the door for the victim to accept a fraudulent certificate as valid--perm= itting future mischief. This would be an interesting way to attack systems= that use certificate pinning. -- T >-----Original Message----- >From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Erik Andersen >Sent: Tuesday, April 01, 2014 5:51 AM >To: pkix@ietf.org >Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates > >Hi Denis, > > > >Did you change your email address? > > > >The start of the last paragraph of section 5 says: > > > >Responding with a "revoked" state to a certificate that has never > >been issued may enable someone to obtain a revocation response for a > >certificate that is not yet issued, but soon will be issued, if the > >certificate serial number of the certificate that will be issued can > >be predicted or guessed by the requestor. > > > >So, assume I am bad guy. I have gotten hold of a OCSP response saying >"revoked" for certificate about to be issued. How can I use that response= to >do nasty things? > > > >Regards, > > > >Erik > > > >From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis >Sent: Tuesday, April 01, 2014 12:02 PM >To: pkix@ietf.org >Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates > > > >Hi Erik > >RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is no= t >the case. >I still consider RFC 2560 (which unclear on many points) better than RFC 6= 960, >since it added text >that is incompatible with the documents from the CAB (CA Browser Forum). > >Would you be able to quote the sentence that you don't fully understand ? > >Denis > > Hi Folk, > > > > In the last paragraph of section 5 of RFC 6960, it is mentioned a >possible threat when the status "revoked" is issued for a certificate alt= er to >be issued. > > > > How can an attacker utilize this situation? > > > > The answer is probably buried somewhere in the hundreds of emails >on 2560bis. > > > > Erik > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > From nobody Tue Apr 1 07:13:33 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9C31A06BE for ; Tue, 1 Apr 2014 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO346sDVzdg0 for ; Tue, 1 Apr 2014 07:13:29 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id A866C1A07A7 for ; Tue, 1 Apr 2014 07:13:28 -0700 (PDT) Received: from ([62.44.135.107]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id NSO30721 for ; Tue, 01 Apr 2014 16:13:21 +0200 From: "Erik Andersen" To: References: <000e01cf4d87$7f5ba570$7e12f050$@x500.eu> <533A8EA8.2080007@free.fr> <002801cf4d98$54ce55d0$fe6b0170$@x500.eu> <195DB2510AAA004391F58E28FCE2120046156CCD@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE2120046156CCD@IMCMBX01.MITRE.ORG> Date: Tue, 1 Apr 2014 16:13:18 +0200 Message-ID: <004c01cf4db4$8a130cb0$9e392610$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJrBMbLtmGj4Pm6iAQDUciTLtjVmAIrPh3BAitnaK0Dh1KD/pmGb0Uw Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/GubLWO-7XIbkj5cNB6pZ56bzTA0 Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:13:30 -0000 Hi T, Thanks for the information. Also very useful. Regards, Erik -----Original Message----- From: Miller, Timothy J. [mailto:tmiller@mitre.org] Sent: Tuesday, April 01, 2014 3:50 PM To: 'Erik Andersen'; pkix@ietf.org Subject: RE: [pkix] OCSP - revoked stte for non-issued certificates An attacker with the ability to replay OCSP responses to a victim can collect "revoked" responses (assuming no nonce) for not-yet-issued serial numbers and then replay them to a victim after those certificates are issued causing the victim to reject those certificates. At the lowest impact, this is simply disruptive. At medium impacts, it could be used as a DoS against the PKI or Subscribers. At worst I could conceivably use this as part of a key rollover attack, where I convince the victim that the legitimate certificate is revoked and open the door for the victim to accept a fraudulent certificate as valid--permitting future mischief. This would be an interesting way to attack systems that use certificate pinning. -- T >-----Original Message----- >From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Erik Andersen >Sent: Tuesday, April 01, 2014 5:51 AM >To: pkix@ietf.org >Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates > >Hi Denis, > > > >Did you change your email address? > > > >The start of the last paragraph of section 5 says: > > > >Responding with a "revoked" state to a certificate that has never > >been issued may enable someone to obtain a revocation response for a > >certificate that is not yet issued, but soon will be issued, if the > >certificate serial number of the certificate that will be issued can > >be predicted or guessed by the requestor. > > > >So, assume I am bad guy. I have gotten hold of a OCSP response saying >"revoked" for certificate about to be issued. How can I use that >response to do nasty things? > > > >Regards, > > > >Erik > > > >From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis >Sent: Tuesday, April 01, 2014 12:02 PM >To: pkix@ietf.org >Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates > > > >Hi Erik > >RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is >not the case. >I still consider RFC 2560 (which unclear on many points) better than >RFC 6960, since it added text that is incompatible with the documents >from the CAB (CA Browser Forum). > >Would you be able to quote the sentence that you don't fully understand ? > >Denis > > Hi Folk, > > > > In the last paragraph of section 5 of RFC 6960, it is mentioned a >possible threat when the status "revoked" is issued for a certificate >alter to be issued. > > > > How can an attacker utilize this situation? > > > > The answer is probably buried somewhere in the hundreds of emails on >2560bis. > > > > Erik > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > From nobody Tue Apr 1 14:39:13 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B882A1A0A18 for ; Tue, 1 Apr 2014 14:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV7d6tnf3Lt2; Tue, 1 Apr 2014 14:39:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A601A0A0C; Tue, 1 Apr 2014 14:39:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: housley@vigilsec.com, draft-housley-pkix-oids@tools.ietf.org, pkix@ietf.org, stephen.farrell@cs.tcd.ie X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401213907.14131.37458.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 14:39:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/ZjSGzm9FAyE5IB-uhL_vxr0SH5U Subject: [pkix] New Version Notification - draft-housley-pkix-oids-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:39:10 -0000 A new version (-02) has been submitted for draft-housley-pkix-oids: http://www.ietf.org/internet-drafts/draft-housley-pkix-oids-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-housley-pkix-oids/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-housley-pkix-oids-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Apr 2 11:16:50 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7451A0398 for ; Wed, 2 Apr 2014 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl0JJmq30qT1 for ; Wed, 2 Apr 2014 11:16:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4C1A0370 for ; Wed, 2 Apr 2014 11:16:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8ECF57FC3A9; Wed, 2 Apr 2014 11:16:32 -0700 (PDT) To: jimsch@augustcellars.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20140402181632.8ECF57FC3A9@rfc-editor.org> Date: Wed, 2 Apr 2014 11:16:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/DUusr-ok4cHJ8aZuRdjMsY5Zshs Cc: pkix@ietf.org, ietf@augustcellars.com, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC6402 (3943) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 18:16:48 -0000 The following errata report has been submitted for RFC6402, "Certificate Management over CMS (CMC) Updates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6402&eid=3943 -------------------------------------- Type: Technical Reported by: Jim Schaad Section: 2.8, Original Text ------------- ChangeSubjectName ::= SEQUENCE { subject Name OPTIONAL, subjectAlt SubjectAltName OPTIONAL } (WITH COMPONENTS {..., subject PRESENT} | COMPONENTS {..., subjectAlt PRESENT} ) Corrected Text -------------- ChangeSubjectName ::= SEQUENCE { subject Name OPTIONAL, subjectAlt [1] SubjectAltName OPTIONAL } (WITH COMPONENTS {..., subject PRESENT} | COMPONENTS {..., subjectAlt PRESENT} ) Notes ----- Both Name and SubjectAltName use the same tag (SEQUENCE) so it is not possible to distinguish between the two fields without having a tag on one of them. This fix adds a tag so that it is possible to differentiate the two fields. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6402 (draft-ietf-pkix-rfc5272-bis-08) -------------------------------------- Title : Certificate Management over CMS (CMC) Updates Publication Date : November 2011 Author(s) : J. Schaad Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 2 16:03:49 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE15B1A041D for ; Wed, 2 Apr 2014 16:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUiHAUL1cCZW for ; Wed, 2 Apr 2014 16:03:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 628E61A040F for ; Wed, 2 Apr 2014 16:03:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC4B5BE38; Thu, 3 Apr 2014 00:03:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUJfg-kjNjvq; Thu, 3 Apr 2014 00:03:36 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.19.227]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 25DBDBE33; Thu, 3 Apr 2014 00:03:36 +0100 (IST) Message-ID: <533C9747.5090502@cs.tcd.ie> Date: Thu, 03 Apr 2014 00:03:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: RFC Errata System , jimsch@augustcellars.com, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com References: <20140402181632.8ECF57FC3A9@rfc-editor.org> In-Reply-To: <20140402181632.8ECF57FC3A9@rfc-editor.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/g07icnoW2sqbagmm1bDM-0IjVIQ Cc: pkix@ietf.org, ietf@augustcellars.com Subject: Re: [pkix] [Technical Errata Reported] RFC6402 (3943) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 23:03:48 -0000 A bug fix that breaks interop? Is that a valid Erratum? S On 04/02/2014 07:16 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6402, > "Certificate Management over CMS (CMC) Updates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6402&eid=3943 > > -------------------------------------- > Type: Technical > Reported by: Jim Schaad > > Section: 2.8, > > Original Text > ------------- > > ChangeSubjectName ::= SEQUENCE { > subject Name OPTIONAL, > subjectAlt SubjectAltName OPTIONAL > } > (WITH COMPONENTS {..., subject PRESENT} | > COMPONENTS {..., subjectAlt PRESENT} ) > > Corrected Text > -------------- > ChangeSubjectName ::= SEQUENCE { > subject Name OPTIONAL, > subjectAlt [1] SubjectAltName OPTIONAL > } > (WITH COMPONENTS {..., subject PRESENT} | > COMPONENTS {..., subjectAlt PRESENT} ) > > Notes > ----- > Both Name and SubjectAltName use the same tag (SEQUENCE) so it is not possible to distinguish between the two fields without having a tag on one of them. This fix adds a tag so that it is possible to differentiate the two fields. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6402 (draft-ietf-pkix-rfc5272-bis-08) > -------------------------------------- > Title : Certificate Management over CMS (CMC) Updates > Publication Date : November 2011 > Author(s) : J. Schaad > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > > From nobody Wed Apr 2 16:31:19 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDE01A001F for ; Wed, 2 Apr 2014 16:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmIOYC9j5NxA for ; Wed, 2 Apr 2014 16:31:14 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 058E21A0005 for ; Wed, 2 Apr 2014 16:31:14 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 937F938EF3; Wed, 2 Apr 2014 16:31:09 -0700 (PDT) From: "Jim Schaad" To: "'Stephen Farrell'" , "'RFC Errata System'" , , , References: <20140402181632.8ECF57FC3A9@rfc-editor.org> <533C9747.5090502@cs.tcd.ie> In-Reply-To: <533C9747.5090502@cs.tcd.ie> Date: Wed, 2 Apr 2014 16:29:17 -0700 Message-ID: <02a201cf4ecb$5e301210$1a903630$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK0qMWj8QOkhs72HhSV0jPYkn9czQI1k3plmSKYIhA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/74l8SN4iJhHi3vVYljwHd5_R-mI Cc: pkix@ietf.org, ietf@augustcellars.com Subject: Re: [pkix] [Technical Errata Reported] RFC6402 (3943) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 23:31:18 -0000 Doesn't break interop - The module fails to compile without the fix. I somehow only used one of the three compilers on my machine which I checked this and it was the wrong one as that oddity of the encoder was not checked by that compiler. Jim > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, April 02, 2014 4:04 PM > To: RFC Errata System; jimsch@augustcellars.com; > Kathleen.Moriarty.ietf@gmail.com; kent@bbn.com; stefan@aaa-sec.com > Cc: ietf@augustcellars.com; pkix@ietf.org > Subject: Re: [Technical Errata Reported] RFC6402 (3943) > > > A bug fix that breaks interop? Is that a valid Erratum? > > S > > On 04/02/2014 07:16 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC6402, > > "Certificate Management over CMS (CMC) Updates". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6402&eid=3943 > > > > -------------------------------------- > > Type: Technical > > Reported by: Jim Schaad > > > > Section: 2.8, > > > > Original Text > > ------------- > > > > ChangeSubjectName ::= SEQUENCE { > > subject Name OPTIONAL, > > subjectAlt SubjectAltName OPTIONAL > > } > > (WITH COMPONENTS {..., subject PRESENT} | > > COMPONENTS {..., subjectAlt PRESENT} ) > > > > Corrected Text > > -------------- > > ChangeSubjectName ::= SEQUENCE { > > subject Name OPTIONAL, > > subjectAlt [1] SubjectAltName OPTIONAL > > } > > (WITH COMPONENTS {..., subject PRESENT} | > > COMPONENTS {..., subjectAlt PRESENT} ) > > > > Notes > > ----- > > Both Name and SubjectAltName use the same tag (SEQUENCE) so it is not > possible to distinguish between the two fields without having a tag on one of > them. This fix adds a tag so that it is possible to differentiate the two fields. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6402 (draft-ietf-pkix-rfc5272-bis-08) > > -------------------------------------- > > Title : Certificate Management over CMS (CMC) Updates > > Publication Date : November 2011 > > Author(s) : J. Schaad > > Category : PROPOSED STANDARD > > Source : Public-Key Infrastructure (X.509) > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > From nobody Wed Apr 2 20:13:18 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437B71A008B for ; Wed, 2 Apr 2014 20:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qhFxgYM_VqE for ; Wed, 2 Apr 2014 20:13:10 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id E7B401A007B for ; Wed, 2 Apr 2014 20:13:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,783,1389704400"; d="scan'208";a="5379512" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 03 Apr 2014 14:05:17 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7396"; a="208139829" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccvi.tcif.telstra.com.au with ESMTP; 03 Apr 2014 14:13:04 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Thu, 3 Apr 2014 14:13:04 +1100 From: "Manger, James" To: Jim Schaad , 'Stephen Farrell' , 'RFC Errata System' , "Kathleen.Moriarty.ietf@gmail.com" , "kent@bbn.com" , "stefan@aaa-sec.com" Date: Thu, 3 Apr 2014 14:13:03 +1100 Thread-Topic: [pkix] [Technical Errata Reported] RFC6402 (3943) Thread-Index: AQK0qMWj8QOkhs72HhSV0jPYkn9czQI1k3plmSKYIhCAAD3jQA== Message-ID: <255B9BB34FB7D647A506DC292726F6E115447F6AC3@WSMSG3153V.srv.dir.telstra.com> References: <20140402181632.8ECF57FC3A9@rfc-editor.org> <533C9747.5090502@cs.tcd.ie> <02a201cf4ecb$5e301210$1a903630$@augustcellars.com> In-Reply-To: <02a201cf4ecb$5e301210$1a903630$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/DpfOPT7ilkDx9mE6zPRP1m_G4iE Cc: "pkix@ietf.org" , "ietf@augustcellars.com" Subject: Re: [pkix] [Technical Errata Reported] RFC6402 (3943) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 03:13:15 -0000 QW5vdGhlciBwcm9ibGVtIHdpdGggdGhlIHNwZWMgYW5kIHRoaXMgZXJyYXRhIGlzIHRoYXQgdXNl cyBhIG5vbi1leGlzdGVudCBBU04uMSB0eXBlOiBTdWJqZWN0QWx0TmFtZS4NCg0KU2hvdWxkIGJl IEdlbmVyYWxOYW1lcyBpbnN0ZWFkLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwa2l4IFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSmltIFNjaGFhZA0KU2VudDogVGh1cnNkYXksIDMgQXByaWwgMjAxNCAx MDoyOSBBTQ0KVG86ICdTdGVwaGVuIEZhcnJlbGwnOyAnUkZDIEVycmF0YSBTeXN0ZW0nOyBLYXRo bGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsga2VudEBiYm4uY29tOyBzdGVmYW5AYWFhLXNl Yy5jb20NCkNjOiBwa2l4QGlldGYub3JnOyBpZXRmQGF1Z3VzdGNlbGxhcnMuY29tDQpTdWJqZWN0 OiBSZTogW3BraXhdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2NDAyICgzOTQzKQ0K DQpEb2Vzbid0IGJyZWFrIGludGVyb3AgLSBUaGUgbW9kdWxlIGZhaWxzIHRvIGNvbXBpbGUgd2l0 aG91dCB0aGUgZml4LiAgSQ0Kc29tZWhvdyBvbmx5IHVzZWQgb25lIG9mIHRoZSB0aHJlZSBjb21w aWxlcnMgb24gbXkgbWFjaGluZSB3aGljaCBJIGNoZWNrZWQNCnRoaXMgYW5kIGl0IHdhcyB0aGUg d3Jvbmcgb25lIGFzIHRoYXQgb2RkaXR5IG9mIHRoZSBlbmNvZGVyIHdhcyBub3QgY2hlY2tlZA0K YnkgdGhhdCBjb21waWxlci4NCg0KSmltDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNk LmllXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDAyLCAyMDE0IDQ6MDQgUE0NCj4gVG86IFJG QyBFcnJhdGEgU3lzdGVtOyBqaW1zY2hAYXVndXN0Y2VsbGFycy5jb207DQo+IEthdGhsZWVuLk1v cmlhcnR5LmlldGZAZ21haWwuY29tOyBrZW50QGJibi5jb207IHN0ZWZhbkBhYWEtc2VjLmNvbQ0K PiBDYzogaWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTsgcGtpeEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzY0MDIgKDM5NDMpDQo+IA0KPiANCj4g QSBidWcgZml4IHRoYXQgYnJlYWtzIGludGVyb3A/ICBJcyB0aGF0IGEgdmFsaWQgRXJyYXR1bT8N Cj4gDQo+IFMNCj4gDQo+IE9uIDA0LzAyLzIwMTQgMDc6MTYgUE0sIFJGQyBFcnJhdGEgU3lzdGVt IHdyb3RlOg0KPiA+IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0 ZWQgZm9yIFJGQzY0MDIsDQo+ID4gIkNlcnRpZmljYXRlIE1hbmFnZW1lbnQgb3ZlciBDTVMgKENN QykgVXBkYXRlcyIuDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0KPiA+IGh0 dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTY0MDImZWlkPTM5 NDMNCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g VHlwZTogVGVjaG5pY2FsDQo+ID4gUmVwb3J0ZWQgYnk6IEppbSBTY2hhYWQgPGlldGZAYXVndXN0 Y2VsbGFycy5jb20+DQo+ID4NCj4gPiBTZWN0aW9uOiAyLjgsDQo+ID4NCj4gPiBPcmlnaW5hbCBU ZXh0DQo+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gICAgICAgQ2hhbmdlU3ViamVjdE5hbWUg Ojo9IFNFUVVFTkNFIHsNCj4gPiAgICAgICAgICAgc3ViamVjdCAgICAgICAgICAgICBOYW1lIE9Q VElPTkFMLA0KPiA+ICAgICAgICAgICBzdWJqZWN0QWx0ICAgICAgICAgIFN1YmplY3RBbHROYW1l IE9QVElPTkFMDQo+ID4gICAgICAgfQ0KPiA+ICAgICAgIChXSVRIIENPTVBPTkVOVFMgey4uLiwg c3ViamVjdCBQUkVTRU5UfSB8DQo+ID4gICAgICAgICAgICAgQ09NUE9ORU5UUyB7Li4uLCBzdWJq ZWN0QWx0IFBSRVNFTlR9ICkNCj4gPg0KPiA+IENvcnJlY3RlZCBUZXh0DQo+ID4gLS0tLS0tLS0t LS0tLS0NCj4gPiAgICAgICBDaGFuZ2VTdWJqZWN0TmFtZSA6Oj0gU0VRVUVOQ0Ugew0KPiA+ICAg ICAgICAgICBzdWJqZWN0ICAgICAgICAgICAgIE5hbWUgT1BUSU9OQUwsDQo+ID4gICAgICAgICAg IHN1YmplY3RBbHQgICAgICAgICAgWzFdIFN1YmplY3RBbHROYW1lIE9QVElPTkFMDQo+ID4gICAg ICAgfQ0KPiA+ICAgICAgIChXSVRIIENPTVBPTkVOVFMgey4uLiwgc3ViamVjdCBQUkVTRU5UfSB8 DQo+ID4gICAgICAgICAgICAgQ09NUE9ORU5UUyB7Li4uLCBzdWJqZWN0QWx0IFBSRVNFTlR9ICkN Cj4gPg0KPiA+IE5vdGVzDQo+ID4gLS0tLS0NCj4gPiBCb3RoIE5hbWUgYW5kIFN1YmplY3RBbHRO YW1lIHVzZSB0aGUgc2FtZSB0YWcgKFNFUVVFTkNFKSBzbyBpdCBpcyBub3QNCj4gcG9zc2libGUg dG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUgdHdvIGZpZWxkcyB3aXRob3V0IGhhdmluZyBhIHRh ZyBvbiBvbmUNCm9mDQo+IHRoZW0uICBUaGlzIGZpeCBhZGRzIGEgdGFnIHNvIHRoYXQgaXQgaXMg cG9zc2libGUgdG8gZGlmZmVyZW50aWF0ZSB0aGUgdHdvDQpmaWVsZHMuDQo+ID4NCj4gPiBJbnN0 cnVjdGlvbnM6DQo+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+IFRoaXMgZXJyYXRhIGlzIGN1cnJlbnRs eSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj4gPiB1c2UgIlJl cGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvciByZWpl Y3RlZC4NCj4gPiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0 eSAoSUVTRykgY2FuIGxvZyBpbiB0bw0KPiA+IGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRo ZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ID4gUkZDNjQwMiAoZHJhZnQtaWV0Zi1wa2l4LXJmYzUyNzItYmlz LTA4KQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gVGl0 bGUgICAgICAgICAgICAgICA6IENlcnRpZmljYXRlIE1hbmFnZW1lbnQgb3ZlciBDTVMgKENNQykg VXBkYXRlcw0KPiA+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBOb3ZlbWJlciAyMDExDQo+ID4gQXV0 aG9yKHMpICAgICAgICAgICA6IEouIFNjaGFhZA0KPiA+IENhdGVnb3J5ICAgICAgICAgICAgOiBQ Uk9QT1NFRCBTVEFOREFSRA0KPiA+IFNvdXJjZSAgICAgICAgICAgICAgOiBQdWJsaWMtS2V5IElu ZnJhc3RydWN0dXJlIChYLjUwOSkNCj4gPiBBcmVhICAgICAgICAgICAgICAgIDogU2VjdXJpdHkN Cj4gPiBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPiA+IFZlcmlmeWluZyBQYXJ0eSAgICAg OiBJRVNHDQo+ID4NCj4gPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KcGtpeCBtYWlsaW5nIGxpc3QNCnBraXhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeA0K From nobody Wed Apr 2 22:01:28 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E771A0041 for ; Wed, 2 Apr 2014 22:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5gRzvgWh8xL for ; Wed, 2 Apr 2014 22:01:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 56A381A0047 for ; Wed, 2 Apr 2014 22:01:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 426467FC39D; Wed, 2 Apr 2014 22:01:14 -0700 (PDT) To: jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20140403050115.426467FC39D@rfc-editor.org> Date: Wed, 2 Apr 2014 22:01:14 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/5GDfTzk1TuzrWzOHUAey7Pa4p0M Cc: tom.biskupic@gmail.com, rfc-editor@rfc-editor.org, pkix@ietf.org Subject: [pkix] [Editorial Errata Reported] RFC4211 (3948) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:01:24 -0000 The following errata report has been submitted for RFC4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4211&eid=3948 -------------------------------------- Type: Editorial Reported by: Tom Biskupic Section: 5.3.4 Original Text ------------- CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, response SEQUENCE OF CertResponse } Corrected Text -------------- CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } Notes ----- The definition in the text is different to the one in the ASN.1 module contained in Appendix F. The correct text is assumed to be the one from Appendix F Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4211 (draft-ietf-pkix-rfc2511bis-08) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) Publication Date : September 2005 Author(s) : J. Schaad Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From tom.biskupic@gmail.com Wed Apr 2 22:28:40 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DBE1A00B4 for ; Wed, 2 Apr 2014 22:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUDIWBoHO-Fd for ; Wed, 2 Apr 2014 22:28:35 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4284E1A00AE for ; Wed, 2 Apr 2014 22:28:34 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so1752404wiv.0 for ; Wed, 02 Apr 2014 22:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ksJrO3Pe2rCU5PjSyWFyjxgHOwiOmc3MG3jlyjs6f1A=; b=J0Qi3Gla1JBpdgJMSCafDRzvao4iPGpeHwqxQH78yWpXFVwQXP5nZkuXb0wNUmITM5 fBzXyaM+xaMQKi7HPFCstTB1JiTvE2vuJLpMgPEtfOOZ3zJhllPUTuwx9jNSLV42T+RN A5slH/dPRihAGfXMcoVP5hkNC8bHOytn2FGyhaMPJ0eLsw7PEzkqtuueoNn0bq+IFWpa 8dYudbKeBZks31eNsFok/0P8MTkI7HYewHyVMSo7cyMFLCOW2gYfUWvJG6JpksscDNTl g0ZX26+GV2LOhvbX7CJz8bCwkl7kgJpPcK7uhH4Ol+jANRjryJ4jps0fQVu9ITJGfQyy dwkQ== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr6772216wjx.8.1396502910542; Wed, 02 Apr 2014 22:28:30 -0700 (PDT) Received: by 10.180.99.2 with HTTP; Wed, 2 Apr 2014 22:28:30 -0700 (PDT) Date: Thu, 3 Apr 2014 16:28:30 +1100 Message-ID: From: Tom Biskupic To: pkix@ietf.org Content-Type: multipart/alternative; boundary=047d7beb9c80e92bb104f61cab49 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/LsGp4SF1z8xflFYtIHiUzL5aW54 Subject: [pkix] Discrepancy between Signature POP RFC 2511 and RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:29:35 -0000 --047d7beb9c80e92bb104f61cab49 Content-Type: text/plain; charset=ISO-8859-1 Hello, There appears to be a discrepancy in the text between RFC 2510 and 4211 in regards signature POP for the case where the EE has an established identity and POPOSigningKeyInput has been omitted. The ASN.1 comment in Section 4.4 of RFC 2510 implies the POP signature should be over the CertReqMessage but in Section 4.1 of RFC 4211 it says it should be over the CertTemplate. In RFC 2511: POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING } -- The signature (using "algorithmIdentifier") is on the -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg -- certReq CertTemplate contains the subject and publicKey values, -- then poposkInput MUST be omitted and the signature MUST be -- computed on the DER-encoded value of CertReqMsg certReq. If *************************************** -- the CertReqMsg certReq CertTemplate does not contain the public -- key and subject values, then poposkInput MUST be present and -- MUST be signed. This strategy ensures that the public key is -- not present in both the poposkInput and CertReqMsg certReq -- CertTemplate fields. But in RFC 4211 section 4.1 point 3 3. The certificate subject places its name in the Certificate Template structure along with the public key. In this case the poposkInput field is omitted from the POPOSigningKey structure. The signature field is computed over the DER-encoded certificate template structure. ****************** Is this an intended change to the protocol or have I misunderstood/missed something? Thanks, Tom Biskupic --047d7beb9c80e92bb104f61cab49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

There appears to be a discrepanc= y in the text between RFC 2510 and 4211 in regards signature POP for the ca= se where the EE has an established identity and=A0POPOSigningKeyInput has been omitted.
The ASN.1 comment in Section 4.4 of RFC 2510 implies the POP signature shou= ld be over the CertReqMessage but in Section 4.1 of RFC 4211 it says it sho= uld be over the CertTemplate.

In = RFC 2511:

POPOSigningKey ::=3D SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }
       -- The signature (using "algorithmIdentifier") is on the
       -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
       -- certReq CertTemplate contains the subject and publicKey values,
       -- then poposkInput MUST be omitted and the signature MUST be
       -- computed on the DER-encoded value of CertReqMsg certReq.  If
=
                          ***************************************
       -- the CertReqMsg certReq CertTemplate does not contain the public
       -- key and subject values, then poposkInput MUST be present and
       -- MUST be signed.  This strategy ensures that the public key is
       -- not present in both the poposkInput and CertReqMsg certReq
       -- CertTemplate fields.

But in RFC 4211 section 4.1 poi=
nt 3
<=
pre style=3D"word-wrap:break-word;white-space:pre-wrap"> 3.  The certificat=
e subject places its name in the Certificate
       Template structure along with the public key.  In this case the
       poposkInput field is omitted from the POPOSigningKey structure.
       The signature field is computed over the DER-encoded certificate
       template structure.
       ******************
Is this an int=
ended change to the protocol or have I misunderstood/missed something?
Thanks,
Tom Biskupic
--047d7beb9c80e92bb104f61cab49-- From nobody Thu Apr 3 02:28:48 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF91A008E for ; Thu, 3 Apr 2014 02:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9F5-akFudxW for ; Thu, 3 Apr 2014 02:28:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 194F61A0117 for ; Thu, 3 Apr 2014 02:28:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99D3CBE50; Thu, 3 Apr 2014 10:28:37 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRwTcr8cBev8; Thu, 3 Apr 2014 10:28:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62D76BE39; Thu, 3 Apr 2014 10:28:37 +0100 (IST) Message-ID: <533D29C5.2080101@cs.tcd.ie> Date: Thu, 03 Apr 2014 10:28:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tom Biskupic , RFC Errata System References: <20140403050115.426467FC39D@rfc-editor.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/kFd4Y2cUvwqdZOXkHf2Y41HvlWc Cc: stefan@aaa-sec.com, Kathleen.Moriarty.ietf@gmail.com, jimsch@exmsft.com, pkix@ietf.org Subject: [pkix] Fun with errata (wa: Re: [Editorial Errata Reported] RFC4211 (3948)) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:28:46 -0000 It would be so nice if people would post a message to the pkix list before posting an erratum. That'd save some errors and wasted time for those who have to later process the errata and would mean that the person reporting could add a link the the list archive to help someone who reads the thing. Thanks, S. On 04/03/2014 06:09 AM, Tom Biskupic wrote: > Sorry I have submitted this against the wrong RFC - it should have been RFC > 4210 (not 4211). I've submitted an errata for the correct RFC. > > Thanks, > > Tom Biskupic > > > On Thu, Apr 3, 2014 at 4:01 PM, RFC Errata System > wrote: > >> The following errata report has been submitted for RFC4211, >> "Internet X.509 Public Key Infrastructure Certificate Request Message >> Format (CRMF)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4211&eid=3948 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Tom Biskupic >> >> Section: 5.3.4 >> >> Original Text >> ------------- >> CertRepMessage ::= SEQUENCE { >> caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate >> OPTIONAL, >> response SEQUENCE OF CertResponse >> } >> >> Corrected Text >> -------------- >> CertRepMessage ::= SEQUENCE { >> caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate >> OPTIONAL, >> response SEQUENCE OF CertResponse >> } >> >> Notes >> ----- >> The definition in the text is different to the one in the ASN.1 module >> contained in Appendix F. The correct text is assumed to be the one from >> Appendix F >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4211 (draft-ietf-pkix-rfc2511bis-08) >> -------------------------------------- >> Title : Internet X.509 Public Key Infrastructure Certificate >> Request Message Format (CRMF) >> Publication Date : September 2005 >> Author(s) : J. Schaad >> Category : PROPOSED STANDARD >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > From nobody Thu Apr 3 02:46:06 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73C1A0090 for ; Thu, 3 Apr 2014 02:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJpKuimdvls0 for ; Thu, 3 Apr 2014 02:46:00 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B2BDC1A0117 for ; Thu, 3 Apr 2014 02:45:58 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id rd3so1601470pab.11 for ; Thu, 03 Apr 2014 02:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7cC3zWgnI/FA6plqlOIke0IWvJWQhDUW54d9aaJyg+Q=; b=AMAKIHZ9efniwGIZ28xMFyuL0wtMH5xaaXXUxnf/7AVqftjA/OnkA0m8N8VbcuRHMN FTag3L2jscgDKVx86r3XYC7R0DU1Gr4iy0Fh/+JOOyVFZkmaucDRTyXjpSL41QpYaWJp E6d/hXPwZfFAM6jGC2u0u3UXqxY51opHWYMPbU6070dQl/9sxzHWiQj0xL7koFSVsgt4 7jf8IWaBn1/ohT2gNurnlUYcnRGmWGJ1jAOsGl6urvlL9H0nrZ2qkZBtSgeNgNxxRfEG 7apz6LATQ4ZQKz59z/NlI6HTvi4yOX+QZRSPolGmdLpLRVDwYP7S+dYIHtpLFE87leLG y8yA== X-Received: by 10.66.155.133 with SMTP id vw5mr6220367pab.124.1396518354560; Thu, 03 Apr 2014 02:45:54 -0700 (PDT) Received: from [192.168.1.40] (c114-76-163-153.blktn4.nsw.optusnet.com.au. [114.76.163.153]) by mx.google.com with ESMTPSA id el14sm22733255pac.31.2014.04.03.02.45.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 02:45:52 -0700 (PDT) References: <20140403050115.426467FC39D@rfc-editor.org> <533D29C5.2080101@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <533D29C5.2080101@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <608692D8-F7BE-41A7-B785-78132DF4D077@gmail.com> X-Mailer: iPhone Mail (11D167) From: Tom Biskupic Date: Thu, 3 Apr 2014 20:45:43 +1100 To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/Wkc6JN-P-_NoRig8up9g3vxB9QM Cc: "stefan@aaa-sec.com" , "Kathleen.Moriarty.ietf@gmail.com" , "jimsch@exmsft.com" , "pkix@ietf.org" , RFC Errata System Subject: Re: [pkix] Fun with errata (wa: Re: [Editorial Errata Reported] RFC4211 (3948)) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 09:46:04 -0000 Will note this for future. I had thought this was the less obtrusive way to p= ost minor editorial errors. Again - sorry for the error with the rfc number. Tom Biskupic > On 3 Apr 2014, at 20:28, Stephen Farrell wrote= : >=20 >=20 > It would be so nice if people would post a message to the > pkix list before posting an erratum. That'd save some errors > and wasted time for those who have to later process the > errata and would mean that the person reporting could add > a link the the list archive to help someone who reads the > thing. >=20 > Thanks, > S. >=20 >> On 04/03/2014 06:09 AM, Tom Biskupic wrote: >> Sorry I have submitted this against the wrong RFC - it should have been R= FC >> 4210 (not 4211). I've submitted an errata for the correct RFC. >>=20 >> Thanks, >>=20 >> Tom Biskupic >>=20 >>=20 >> On Thu, Apr 3, 2014 at 4:01 PM, RFC Errata System >> wrote: >>=20 >>> The following errata report has been submitted for RFC4211, >>> "Internet X.509 Public Key Infrastructure Certificate Request Message >>> Format (CRMF)". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D4211&eid=3D3948 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Tom Biskupic >>>=20 >>> Section: 5.3.4 >>>=20 >>> Original Text >>> ------------- >>> CertRepMessage ::=3D SEQUENCE { >>> caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate >>> OPTIONAL, >>> response SEQUENCE OF CertResponse >>> } >>>=20 >>> Corrected Text >>> -------------- >>> CertRepMessage ::=3D SEQUENCE { >>> caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate >>> OPTIONAL, >>> response SEQUENCE OF CertResponse >>> } >>>=20 >>> Notes >>> ----- >>> The definition in the text is different to the one in the ASN.1 module >>> contained in Appendix F. The correct text is assumed to be the one from >>> Appendix F >>>=20 >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC4211 (draft-ietf-pkix-rfc2511bis-08) >>> -------------------------------------- >>> Title : Internet X.509 Public Key Infrastructure Certifica= te >>> Request Message Format (CRMF) >>> Publication Date : September 2005 >>> Author(s) : J. Schaad >>> Category : PROPOSED STANDARD >>> Source : Public-Key Infrastructure (X.509) >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>=20 From nobody Thu Apr 3 08:22:51 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39151A0045 for ; Wed, 2 Apr 2014 22:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E77X9rsT9Rbn for ; Wed, 2 Apr 2014 22:08:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id E4C731A0062 for ; Wed, 2 Apr 2014 22:08:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C006B7FC39D; Wed, 2 Apr 2014 22:08:09 -0700 (PDT) To: cadams@site.uottawa.ca, stephen.farrell@cs.tcd.ie, toka@ssh.com, tmononen@safenet-inc.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20140403050809.C006B7FC39D@rfc-editor.org> Date: Wed, 2 Apr 2014 22:08:09 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/cm1uf7ZHMU6JBPeikit0lGR7nUM X-Mailman-Approved-At: Thu, 03 Apr 2014 08:22:46 -0700 Cc: rfc-editor@rfc-editor.org, pkix@ietf.org Subject: [pkix] [Editorial Errata Reported] RFC4210 (3949) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 05:08:19 -0000 The following errata report has been submitted for RFC4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4210&eid=3949 -------------------------------------- Type: Editorial Reported by: Tom Biskupic Section: 5.3.4 Original Text ------------- CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, response SEQUENCE OF CertResponse } Corrected Text -------------- CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } Notes ----- The definition in the text is different to the one in the ASN.1 module contained in Appendix F. The correct text is assumed to be the one from Appendix F Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4210 (draft-ietf-pkix-rfc2510bis-09) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) Publication Date : September 2005 Author(s) : C. Adams, S. Farrell, T. Kause, T. Mononen Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 4 06:52:08 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BE1A0348 for ; Thu, 3 Apr 2014 15:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71fA3jHKCwI4 for ; Thu, 3 Apr 2014 15:53:36 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 75D971A0346 for ; Thu, 3 Apr 2014 15:53:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 865271E4366; Thu, 3 Apr 2014 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uSP2uOscFms; Thu, 3 Apr 2014 15:52:44 -0700 (PDT) Received: from [192.168.1.3] (pool-68-238-162-118.washdc.fios.verizon.net [68.238.162.118]) by c8a.amsl.com (Postfix) with ESMTPSA id 4EB5F1E41DE; Thu, 3 Apr 2014 15:52:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alice Russo In-Reply-To: Date: Thu, 3 Apr 2014 18:53:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7E1C4C-A850-495E-9F6F-DA9734AE90C3@amsl.com> References: <20140403050115.426467FC39D@rfc-editor.org> To: Tom Biskupic X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/FdmRtVGvKZEYGYLLphRaI76ELso X-Mailman-Approved-At: Fri, 04 Apr 2014 06:52:06 -0700 Cc: Stefan Santesson , Kathleen.Moriarty.ietf@gmail.com, jimsch@exmsft.com, pkix@ietf.org, RFC Errata System Subject: Re: [pkix] [Editorial Errata Reported] RFC4211 (3948) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 22:53:41 -0000 FYI, the erratum mistakenly reported for RFC 4211 has been removed. Thank you. RFC Editor/ar On Apr 3, 2014, at 1:09 AM, Tom Biskupic wrote: > Sorry I have submitted this against the wrong RFC - it should have = been RFC 4210 (not 4211). I've submitted an errata for the correct RFC. >=20 > Thanks, >=20 > Tom Biskupic >=20 >=20 > On Thu, Apr 3, 2014 at 4:01 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC4211, > "Internet X.509 Public Key Infrastructure Certificate Request Message = Format (CRMF)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4211&eid=3D3948 >=20 > -------------------------------------- > Type: Editorial > Reported by: Tom Biskupic >=20 > Section: 5.3.4 >=20 > Original Text > ------------- > CertRepMessage ::=3D SEQUENCE { > caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate > OPTIONAL, > response SEQUENCE OF CertResponse > } >=20 > Corrected Text > -------------- > CertRepMessage ::=3D SEQUENCE { > caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate > OPTIONAL, > response SEQUENCE OF CertResponse > } >=20 > Notes > ----- > The definition in the text is different to the one in the ASN.1 module = contained in Appendix F. The correct text is assumed to be the one from = Appendix F >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC4211 (draft-ietf-pkix-rfc2511bis-08) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure = Certificate Request Message Format (CRMF) > Publication Date : September 2005 > Author(s) : J. Schaad > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From cadams@eecs.uottawa.ca Thu Apr 3 14:06:43 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0FA1A01D9 for ; Thu, 3 Apr 2014 14:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL3VayyxA89T for ; Thu, 3 Apr 2014 14:06:36 -0700 (PDT) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) by ietfa.amsl.com (Postfix) with ESMTP id C07441A01CA for ; Thu, 3 Apr 2014 14:06:35 -0700 (PDT) Received: from adams780 (adams-780.site.uottawa.ca [137.122.91.213]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.4) with ESMTP id s33L5rl8097713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Apr 2014 17:05:53 -0400 (EDT) (envelope-from cadams@eecs.uottawa.ca) From: "Carlisle Adams" To: "'RFC Errata System'" , , , , , , , , References: <20140403050809.C006B7FC39D@rfc-editor.org> In-Reply-To: <20140403050809.C006B7FC39D@rfc-editor.org> Date: Thu, 3 Apr 2014 17:05:53 -0400 Organization: Univ. d'/of Ottawa Message-ID: <011401cf4f80$80ccb020$82661060$@eecs.uottawa.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZUu9fknA+NCOSsiqCy09iF8JocppsWGXw Content-Language: en-us x-ms-exchange-organization-originalclientipaddress: 10.32.32.63 x-ms-exchange-organization-originalserveripaddress: ::1 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/KYLEz4jE-8HxAN43VI6QZS8LIm4 X-Mailman-Approved-At: Fri, 04 Apr 2014 06:52:05 -0700 Cc: pkix@ietf.org Subject: Re: [pkix] [Editorial Errata Reported] RFC4210 (3949) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 00:17:26 -0000 Hello, I agree that this is an error -- the correct text is what is in Appendix F. Note that this is not the only such revision that should be made. For example, the same error appears in Section 5.2.5 for OOBCert ::= Certificate and in Section 5.3.4 for CertOrEncCert ::= CHOICE { certificate [0] Certificate, encryptedCert [1] EncryptedValue } (in both cases, "Certificate" should be "CMPCertificate"). Perhaps there are 1 or 2 other places as well that I haven't noticed. I think at one point Appendix F got edited but the main body of the spec did not. Note that this does not affect implementation or interoperability since Appendix F is the official ASN.1 specification, but it would still be nice to have consistency throughout. Thanks very much for catching this! Carlisle Adams. -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: April-03-14 1:08 AM To: cadams@site.uottawa.ca; stephen.farrell@cs.tcd.ie; toka@ssh.com; tmononen@safenet-inc.com; stephen.farrell@cs.tcd.ie; Kathleen.Moriarty.ietf@gmail.com; kent@bbn.com; stefan@aaa-sec.com Cc: tom.biskupic@gmail.com; pkix@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC4210 (3949) The following errata report has been submitted for RFC4210, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4210&eid=3949 -------------------------------------- Type: Editorial Reported by: Tom Biskupic Section: 5.3.4 Original Text ------------- CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, response SEQUENCE OF CertResponse } Corrected Text -------------- CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } Notes ----- The definition in the text is different to the one in the ASN.1 module contained in Appendix F. The correct text is assumed to be the one from Appendix F Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4210 (draft-ietf-pkix-rfc2510bis-09) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) Publication Date : September 2005 Author(s) : C. Adams, S. Farrell, T. Kause, T. Mononen Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 9 18:41:06 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883561A053B for ; Wed, 9 Apr 2014 18:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVA2LjGlx0Lc for ; Wed, 9 Apr 2014 18:41:02 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 637D31A063A for ; Wed, 9 Apr 2014 18:41:01 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so3298755wgh.29 for ; Wed, 09 Apr 2014 18:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3RVd/v2V6kFkVy2WpkFWuL2oBrzWGwpl98pxJj4r9+U=; b=0JNiziWkAghTb9KoDlzuvnpdf6mQwY/Y0luy3hZabdJOarmM36exFHTP3h3qn0uxI/ RK45gVykqRKk9IZ9kqk4X2lYOdoJT/M4xkjiQtxX7EhlZnkWHVS5Xv99OIQ+yrtpfKNp ZyAcpYERCUcni9uSUilEufa4h/9cPuD0VT2dtTqW9KBVjmUpY4bmBE9xqzsYi2xvxRsh YfNE8yfiyclvdCZPcS/i3/bXmn+ed+iW0/cP5wTS/jFFSrB/6dg8ArV+aJfh+x1Oi6Hx kEOzicDU8oLqmzGSSpQmNbNxWcRAYIWTD0OmJz4ucjoDFqgFqaI8aCzReXnKXPS2pdVq cDKw== MIME-Version: 1.0 X-Received: by 10.194.243.3 with SMTP id wu3mr12375550wjc.29.1397094059996; Wed, 09 Apr 2014 18:40:59 -0700 (PDT) Received: by 10.180.99.2 with HTTP; Wed, 9 Apr 2014 18:40:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 11:40:59 +1000 Message-ID: From: Tom Biskupic To: "pkix@ietf.org" Content-Type: multipart/alternative; boundary=089e013d14c42b055704f6a64fc1 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/Y2qKIyaI-9a1X5teuzy6e6BvCgo Subject: Re: [pkix] Discrepancy between Signature POP RFC 2511 and RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 01:41:03 -0000 --089e013d14c42b055704f6a64fc1 Content-Type: text/plain; charset=ISO-8859-1 Hello, Sorry to nag but did anyone have any thoughts on this? Thanks, Tom Biskupic On Thu, Apr 3, 2014 at 4:28 PM, Tom Biskupic wrote: > Hello, > > There appears to be a discrepancy in the text between RFC 2510 and 4211 in > regards signature POP for the case where the EE has an established identity > and POPOSigningKeyInput has been omitted. > The ASN.1 comment in Section 4.4 of RFC 2510 implies the POP signature > should be over the CertReqMessage but in Section 4.1 of RFC 4211 it says it > should be over the CertTemplate. > > In RFC 2511: > > POPOSigningKey ::= SEQUENCE { > poposkInput [0] POPOSigningKeyInput OPTIONAL, > algorithmIdentifier AlgorithmIdentifier, > signature BIT STRING } > -- The signature (using "algorithmIdentifier") is on the > -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg > -- certReq CertTemplate contains the subject and publicKey values, > -- then poposkInput MUST be omitted and the signature MUST be > -- computed on the DER-encoded value of CertReqMsg certReq. If > > *************************************** > -- the CertReqMsg certReq CertTemplate does not contain the public > -- key and subject values, then poposkInput MUST be present and > -- MUST be signed. This strategy ensures that the public key is > -- not present in both the poposkInput and CertReqMsg certReq > -- CertTemplate fields. > > > But in RFC 4211 section 4.1 point 3 > > 3. The certificate subject places its name in the Certificate > Template structure along with the public key. In this case the > poposkInput field is omitted from the POPOSigningKey structure. > The signature field is computed over the DER-encoded certificate > template structure. > > ****************** > > Is this an intended change to the protocol or have I misunderstood/missed something? > > Thanks, > > Tom Biskupic > > --089e013d14c42b055704f6a64fc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Sorry to nag but did anyone have= any thoughts on this?

Thanks,

Tom Biskupic


On Thu, Apr 3, 2014 at 4:28 PM, Tom Biskupic= <tom.biskupic@gmail.com> wrote:
Hello,

There appears to be a discrepanc= y in the text between RFC 2510 and 4211 in regards signature POP for the ca= se where the EE has an established identity and=A0POPOSigningKeyInput has been omitted.
The ASN.1 comment in Section 4.4 of RFC 2510 implies the POP signature shou= ld be over the CertReqMessage but in Section 4.1 of RFC 4211 it says it sho= uld be over the CertTemplate.

In RFC 2511:<= /div>

POPOSigningKey ::=3D SEQ=
UENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }
       -- The signature (using "algorithmIdentifier") is on the
       -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
       -- certReq CertTemplate contains the subject and publicKey values,
       -- then poposkInput MUST be omitted and the signature MUST be
       -- computed on the DER-encoded value of CertReqMsg certReq.  If
                 =
         ***************************************
       -- the CertReqMsg certReq CertTemplate does not contain the public
       -- key and subject values, then poposkInput MUST be present and
       -- MUST be signed.  This strategy ensures that the public key is
       -- not present in both the poposkInput and CertReqMsg certReq
       -- CertTemplate fields.

But in RFC 4211 section 4.1 point 3
 3.  The certificate subject places =
its name in the Certificate
       Template structure along with the public key.  In this case the
       poposkInput field is omitted from the POPOSigningKey structure.
       The signature field is computed over the DER-encoded certificate
       template structure.
       ******************
Is this an int=
ended change to the protocol or have I misunderstood/missed something?
Thanks,
Tom Biskupic

--089e013d14c42b055704f6a64fc1-- From nobody Thu Apr 10 09:23:19 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17291A02FD for ; Thu, 10 Apr 2014 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C69flVlwDP6B for ; Thu, 10 Apr 2014 09:23:16 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id E5BB91A02E0 for ; Thu, 10 Apr 2014 09:23:15 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B085838EA2; Thu, 10 Apr 2014 09:23:14 -0700 (PDT) From: "Jim Schaad" To: "'Tom Biskupic'" , References: In-Reply-To: Date: Thu, 10 Apr 2014 09:21:19 -0700 Message-ID: <01ea01cf54d8$e85e5880$b91b0980$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EB_01CF549E.3C02DBE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIdVuvh+nc9T+wAT6GwXrsB4mOC0QJIj7uamly/KdA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/dVFsRBABumAqfZbwnCl2-yYXzCY Subject: Re: [pkix] Discrepancy between Signature POP RFC 2511 and RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:23:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EB_01CF549E.3C02DBE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There was no change intented. I would note that 4211 includes the following text in the description of the signature field signature contains the POP value produce. If poposkInput is present, the signature is computed over the DER-encoded value of poposkInput. If poposkInput is absent, the signature is computed over the DER-encoded value of certReq. Which is the same as the comment in 2511. Jim From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Tom Biskupic Sent: Wednesday, April 09, 2014 6:41 PM To: pkix@ietf.org Subject: Re: [pkix] Discrepancy between Signature POP RFC 2511 and RFC 4211 Hello, Sorry to nag but did anyone have any thoughts on this? Thanks, Tom Biskupic On Thu, Apr 3, 2014 at 4:28 PM, Tom Biskupic wrote: Hello, There appears to be a discrepancy in the text between RFC 2510 and 4211 in regards signature POP for the case where the EE has an established identity and POPOSigningKeyInput has been omitted. The ASN.1 comment in Section 4.4 of RFC 2510 implies the POP signature should be over the CertReqMessage but in Section 4.1 of RFC 4211 it says it should be over the CertTemplate. In RFC 2511: POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING } -- The signature (using "algorithmIdentifier") is on the -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg -- certReq CertTemplate contains the subject and publicKey values, -- then poposkInput MUST be omitted and the signature MUST be -- computed on the DER-encoded value of CertReqMsg certReq. If *************************************** -- the CertReqMsg certReq CertTemplate does not contain the public -- key and subject values, then poposkInput MUST be present and -- MUST be signed. This strategy ensures that the public key is -- not present in both the poposkInput and CertReqMsg certReq -- CertTemplate fields. But in RFC 4211 section 4.1 point 3 3. The certificate subject places its name in the Certificate Template structure along with the public key. In this case the poposkInput field is omitted from the POPOSigningKey structure. The signature field is computed over the DER-encoded certificate template structure. ****************** Is this an intended change to the protocol or have I misunderstood/missed something? Thanks, Tom Biskupic ------=_NextPart_000_01EB_01CF549E.3C02DBE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was no change intented.  I would note that 4211 includes = the following text in the description of the signature = field

 

      signature contains the POP value = produce.  If poposkInput is

      present, the signature is computed = over the DER-encoded value of

      poposkInput.  If poposkInput is = absent, the signature is computed

      over the DER-encoded value of = certReq.

 

Which is the same as the comment in 2511.

 

Jim

 

 

From:= = pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Tom = Biskupic
Sent: Wednesday, April 09, 2014 6:41 PM
To: = pkix@ietf.org
Subject: Re: [pkix] Discrepancy between = Signature POP RFC 2511 and RFC 4211

 

Hello,

 

Sorry to nag but did anyone have any thoughts on = this?

 

Thanks,

 

Tom Biskupic

 

 

On Thu, Apr 3, 2014 at 4:28 PM, Tom Biskupic <tom.biskupic@gmail.com> = wrote:

Hello,

 

There appears to be a discrepancy in the text between = RFC 2510 and 4211 in regards signature POP for the case where the EE has = an established identity and POPOSigningKeyInput has been = omitted.

The ASN.1 comment = in Section 4.4 of RFC 2510 implies the POP signature should be over the = CertReqMessage but in Section 4.1 of RFC 4211 it says it should be over = the CertTemplate.

 

In RFC 2511:

 

POPOSigningKey ::=3D =
SEQUENCE {
       =
poposkInput         [0] =
POPOSigningKeyInput =
OPTIONAL,
       =
algorithmIdentifier     =
AlgorithmIdentifier,
     &=
nbsp; =
signature          &nbs=
p;    BIT STRING =
}
       -- The =
signature (using "algorithmIdentifier") is on =
the
       -- =
DER-encoded value of poposkInput.  NOTE: If the =
CertReqMsg
       -- =
certReq CertTemplate contains the subject and publicKey =
values,
       -- =
then poposkInput MUST be omitted and the signature MUST =
be
       -- computed =
on the DER-encoded value of CertReqMsg certReq.  =
If
   &nb=
sp;           &nbs=
p;          =
***************************************
  =
     -- the CertReqMsg certReq CertTemplate does not =
contain the =
public
       -- key =
and subject values, then poposkInput MUST be present =
and
       -- MUST be =
signed.  This strategy ensures that the public key =
is
       -- not =
present in both the poposkInput and CertReqMsg =
certReq
       -- =
CertTemplate fields.
 
But in RFC =
4211 section 4.1 point 3
 3.  The =
certificate subject places its name in the =
Certificate
       =
Template structure along with the public key.  In this case =
the
       =
poposkInput field is omitted from the POPOSigningKey =
structure.
       The =
signature field is computed over the DER-encoded =
certificate
       =
template structure.
   &nb=
sp;   ******************
Is this an intended change to =
the protocol or have I misunderstood/missed =
something?
 
&=
nbsp;
Thanks,
Tom =
Biskupic

 

------=_NextPart_000_01EB_01CF549E.3C02DBE0-- From nobody Fri Apr 11 04:58:19 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091191A0649 for ; Fri, 11 Apr 2014 04:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE4-8BXE0IiS for ; Fri, 11 Apr 2014 04:58:16 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id 096121A01DA for ; Fri, 11 Apr 2014 04:58:15 -0700 (PDT) Received: from ([194.239.2.160]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id XPR42311 for ; Fri, 11 Apr 2014 13:58:11 +0200 From: "Erik Andersen" To: "PKIX" Date: Fri, 11 Apr 2014 13:58:08 +0200 Message-ID: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CF558E.14950060" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOw== Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/gSrT0W0ReEX9fQDIEa2o9ZqLiog Subject: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 11:58:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CF558E.14950060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is it clear than OCSP can only be used for checking status of public-key certificates and not for attribute certificates? Erik ------=_NextPart_000_000A_01CF558E.14950060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is it clear than OCSP can only be used for checking = status of public-key certificates and not for attribute = certificates?

 

Erik

------=_NextPart_000_000A_01CF558E.14950060-- From nobody Fri Apr 11 05:09:23 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0B61A0649 for ; Fri, 11 Apr 2014 05:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbZzDGvRTTvu for ; Fri, 11 Apr 2014 05:09:19 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA71A0651 for ; Fri, 11 Apr 2014 05:09:17 -0700 (PDT) Received: from [10.40.114.254] (unknown [78.250.169.95]) by smtp5-g21.free.fr (Postfix) with ESMTP id 84791D48070 for ; Fri, 11 Apr 2014 14:09:11 +0200 (CEST) Message-ID: <5347DB6A.6020609@free.fr> Date: Fri, 11 Apr 2014 14:09:14 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> In-Reply-To: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> Content-Type: multipart/alternative; boundary="------------010604030509070902090706" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/wEv7ZVaZ37Y8P8fPHscTqMeTBjU Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 12:09:21 -0000 This is a multi-part message in MIME format. --------------010604030509070902090706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Erik, Please take a look at the relevant RFCs before raising such a question to this mailing list: RFC 6960: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. RFC 2560: In lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of a certificate (cf. [RFC2459], Section 3.3). Denis > Is it clear than OCSP can only be used for checking status of > public-key certificates and not for attribute certificates? > > Erik > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------010604030509070902090706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Erik,

Please take a look at the relevant RFCs before raising such a question to this mailing list:

      RFC 6960:

  This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs.


RFC 2560:
   In lieu of or as a supplement to checking against a periodic CRL, it
   may be necessary to obtain timely information regarding the
   revocation status of a certificate (cf. [RFC2459], Section 3.3).
Denis

Is it clear than OCSP can only be used for checking status of public-key certificates and not for attribute certificates?

 

Erik



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------010604030509070902090706-- From nobody Fri Apr 11 05:26:43 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160E21A022D for ; Fri, 11 Apr 2014 05:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.81 X-Spam-Level: * X-Spam-Status: No, score=1.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OkXZQid_o63 for ; Fri, 11 Apr 2014 05:26:39 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB051A0158 for ; Fri, 11 Apr 2014 05:26:39 -0700 (PDT) Received: from ([194.239.2.160]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id XQL67334 for ; Fri, 11 Apr 2014 14:26:34 +0200 From: "Erik Andersen" To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> In-Reply-To: <5347DB6A.6020609@free.fr> Date: Fri, 11 Apr 2014 14:26:29 +0200 Message-ID: <001801cf5581$4841aec0$d8c50c40$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CF5592.0BD0C050" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG/+lgCTTm0O0fUfLlk3oIfj32E1gFYE2fpmyBKMQA= Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/kF86vbYlNXwaW3rNGUxoR1AjKVU Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 12:26:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CF5592.0BD0C050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Denis, I did study RFC 6960, especially the ASN.1, and I did not see anything that prevents checking of attribute certificates, but knowing myself I could miss something. I also know that in PKIX terminology a certificate is synonymous to a public-key certificate. Kind regards, Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Friday, April 11, 2014 2:09 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Erik, Please take a look at the relevant RFCs before raising such a question to this mailing list: RFC 6960: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. RFC 2560: In lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of a certificate (cf. [RFC2459], Section 3.3). Denis Is it clear than OCSP can only be used for checking status of public-key certificates and not for attribute certificates? Erik _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0019_01CF5592.0BD0C050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

I did study RFC 6960, = especially the ASN.1, and I did not see anything that prevents checking = of attribute certificates, but knowing myself I could miss something. I = also know that in PKIX terminology a certificate is synonymous to a = public-key certificate.

 

Kind = regards,

 

Erik =

 

From: pkix = [mailto:pkix-bounces@ietf.org] On Behalf Of Denis
Sent: = Friday, April 11, 2014 2:09 PM
To: = pkix@ietf.org
Subject: Re: [pkix] ACs an = OCSP

 

Erik,

Please take a look at the relevant RFCs = before raising such a question to this mailing list:<= /p>

 

RFC = 6960:

  This document = specifies a protocol useful in determining the current status of a = digital certificate without requiring CRLs.


RFC 2560:

   In lieu =
of or as a supplement to checking against a periodic CRL, =
it
   may be necessary to obtain timely =
information regarding the
   revocation =
status of a certificate (cf. [RFC2459], Section 3.3).

Denis

Is = it clear than OCSP can only be used for checking status of public-key = certificates and not for attribute certificates?

 

Erik




=

_______________________________________________
=
pkix mailing list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix

 

------=_NextPart_000_0019_01CF5592.0BD0C050-- From nobody Fri Apr 11 06:54:56 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AC31A069B for ; Fri, 11 Apr 2014 06:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.199 X-Spam-Level: X-Spam-Status: No, score=-99.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE4PlQSRIswz for ; Fri, 11 Apr 2014 06:54:51 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6A96D1A0694 for ; Fri, 11 Apr 2014 06:54:51 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 688BCF2C04B; Fri, 11 Apr 2014 09:54:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 8SkH+opr9YUa; Fri, 11 Apr 2014 09:54:18 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 54473F2C07F; Fri, 11 Apr 2014 09:54:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-33-157936755 From: Russ Housley In-Reply-To: <001801cf5581$4841aec0$d8c50c40$@x500.eu> Date: Fri, 11 Apr 2014 09:54:07 -0400 Message-Id: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/mkdlCiM94cZ8-AC9dTFeLopkykg Cc: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:54:53 -0000 --Apple-Mail-33-157936755 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RFC 3281 says: 6. Revocation In many environments, the validity period of an AC is less than the time required to issue and distribute revocation information. Therefore, short-lived ACs typically do not require revocation support. However, long-lived ACs and environments where ACs enable high value transactions MAY require revocation support. Two revocation schemes are defined, and the AC issuer should elect the one that is best suited to the environment in which the AC will be employed. "Never revoke" scheme: ACs may be marked so that the relying party understands that no revocation status information will be made available. The noRevAvail extension is defined in section 4.3.6, and the noRevAvail extension MUST be present in the AC to indicate use of this scheme. Where no noRevAvail is present, the AC issuer is implicitly stating that revocation status checks are supported, and some revocation method MUST be provided to allow AC verifiers to establish the revocation status of the AC. "Pointer in AC" scheme: ACs may "point" to sources of revocation status information, using either an authorityInfoAccess extension or a crlDistributionPoints extension within the AC. For AC users, the "never revoke" scheme MUST be supported, and the "pointer in AC" scheme SHOULD be supported. If only the "never revoke" scheme is supported, then all ACs that do not contain a noRevAvail extension, MUST be rejected. For AC issuers, the "never revoke" scheme MUST be supported. If all ACs that will ever be issued by that AC issuer, contains a noRevAvail extension, the "pointer in AC" scheme need not be supported. If any AC can be issued that does not contain the noRevAvail extension, the "pointer in AC" scheme MUST be supported. An AC MUST NOT contain both a noRevAvail and a "pointer in AC". An AC verifier MAY use any source for AC revocation status information. So, my conclusion is that OCSP could support ACs, but I am not aware of = anyone doing so. Russ On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote: > Hi Denis, > =20 > I did study RFC 6960, especially the ASN.1, and I did not see anything = that prevents checking of attribute certificates, but knowing myself I = could miss something. I also know that in PKIX terminology a certificate = is synonymous to a public-key certificate. > =20 > Kind regards, > =20 > Erik --Apple-Mail-33-157936755 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii RFC = 3281 says:

6. = Revocation

   In many environments, = the validity period of an AC is less than the
  =  time required to issue and distribute revocation = information.
   Therefore, short-lived ACs typically = do not require revocation
   support.  However, = long-lived ACs and environments where ACs enable
  =  high value transactions MAY require revocation = support.

   Two revocation schemes = are defined, and the AC issuer should elect
   the = one that is best suited to the environment in which the AC = will
   be employed.

  =  "Never revoke" scheme:

    =   ACs may be marked so that the relying party understands that = no
      revocation status information will be = made available.  The
      noRevAvail = extension is defined in section 4.3.6, and the
    =   noRevAvail extension MUST be present in the AC to indicate use = of
      this = scheme.

      Where no = noRevAvail is present, the AC issuer is implicitly
  =     stating that revocation status checks are supported, and = some
      revocation method MUST be provided = to allow AC verifiers to
      establish the = revocation status of the AC.

  =  "Pointer in AC" scheme:

    =   ACs may "point" to sources of revocation status information, = using
      either an authorityInfoAccess = extension or a crlDistributionPoints
      = extension within the AC.

   For AC = users, the "never revoke" scheme MUST be supported, and = the
   "pointer in AC" scheme SHOULD be supported. =  If only the "never
   revoke" scheme is = supported, then all ACs that do not contain a
  =  noRevAvail extension, MUST be = rejected.

   For AC issuers, the = "never revoke" scheme MUST be supported.  If all
  =  ACs that will ever be issued by that AC issuer, contains a = noRevAvail
   extension, the "pointer in AC" scheme = need not be supported.  If any
   AC can be = issued that does not contain the noRevAvail extension, = the
   "pointer in AC" scheme MUST be = supported.

   An AC MUST NOT contain = both a noRevAvail and a "pointer in AC".

  =  An AC verifier MAY use any source for AC revocation = status
   information.

So, = my conclusion is that OCSP could support ACs, but I am not aware of = anyone doing = so.

Russ


=
On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote:

Hi = Denis,
 
I = did study RFC 6960, especially the ASN.1, and I did not see anything = that prevents checking of attribute certificates, but knowing myself I = could miss something. I also know that in PKIX terminology a certificate = is synonymous to a public-key certificate.
Kind = regards,
 
To: Erik Andersen Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwE2VPEAAACaOoAAAyy1gA== Date: Fri, 11 Apr 2014 13:58:04 +0000 Message-ID: <2EB47F8A-3B03-499B-9B1C-4E179610F967@ttu.edu> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> In-Reply-To: <001801cf5581$4841aec0$d8c50c40$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.118.242.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <076BA1B555B5204DB047F1E9633E6680@default.ttu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TechMail-Edge-Route: TTU Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/Wxm6PqPmz80OA40QgF-GDLZJz5k Cc: "pkix@ietf.org" Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:58:13 -0000 The relevant point is to realize that anyone can add an extended AC to a ce= rtificate. This does not require signature by the issuing authority, only b= y the authority adding the AC. So you would have to set up your OCSP checki= ng independently for each relevant authority. Alan On Apr 11, 2014, at 7:26 AM, Erik Andersen wrote: > Hi Denis, > =20 > I did study RFC 6960, especially the ASN.1, and I did not see anything th= at prevents checking of attribute certificates, but knowing myself I could = miss something. I also know that in PKIX terminology a certificate is synon= ymous to a public-key certificate. > =20 > Kind regards, > =20 > Erik > =20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis > Sent: Friday, April 11, 2014 2:09 PM > To: pkix@ietf.org > Subject: Re: [pkix] ACs an OCSP > =20 > Erik, >=20 > Please take a look at the relevant RFCs before raising such a question to= this mailing list: > =20 > RFC 6960: > This document specifies a protocol useful in determining the current st= atus of a digital certificate without requiring CRLs. >=20 >=20 > RFC 2560: > In lieu of or as a supplement to checking against a periodic CRL, it > may be necessary to obtain timely information regarding the > revocation status of a certificate (cf. [RFC2459], Section 3.3). > Denis >=20 > Is it clear than OCSP can only be used for checking status of public-key = certificates and not for attribute certificates? > =20 > Erik >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Fri Apr 11 07:31:09 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E69A1A06A1 for ; Fri, 11 Apr 2014 07:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vX5xNSYFWuR for ; Fri, 11 Apr 2014 07:31:05 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9B1A06D4 for ; Fri, 11 Apr 2014 07:31:05 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C71441A0095; Fri, 11 Apr 2014 16:31:03 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6rGTq-1Oe2Xl; Fri, 11 Apr 2014 16:30:55 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 4362C1A0096; Fri, 11 Apr 2014 16:30:55 +0200 (CEST) Received: from [10.53.40.204] (port=17320 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WYcTm-0008AY-Im; Fri, 11 Apr 2014 16:30:54 +0200 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 11 Apr 2014 16:30:54 +0200 Message-ID: <5347FC9D.20101@secunet.com> Date: Fri, 11 Apr 2014 16:30:53 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Russ Housley , Erik Andersen References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/49QdR6hV6zl5VeqiuASu7vVlv7Y Cc: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:31:07 -0000 > So, my conclusion is that OCSP could support ACs, but I am not aware of anyone doing so. OCSP is mandatory for ACs corresponding to qualified certificates in Germany. There might not be too many of them out there, but they exist. -- Johannes From nobody Fri Apr 11 07:50:27 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE211A0701 for ; Fri, 11 Apr 2014 07:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R33OD7keHvNh for ; Fri, 11 Apr 2014 07:50:25 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id 14E601A06F9 for ; Fri, 11 Apr 2014 07:50:05 -0700 (PDT) Received: from [10.40.114.254] (unknown [78.250.169.95]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0135CD481A6 for ; Fri, 11 Apr 2014 16:49:59 +0200 (CEST) Message-ID: <5348011A.6010902@free.fr> Date: Fri, 11 Apr 2014 16:50:02 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020807000400000002000302" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/LNzjWkZ-NPnm3j5jQxUWENAJDbI Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:50:26 -0000 This is a multi-part message in MIME format. --------------020807000400000002000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Russ, I do not believe that your conclusion is correct, since the only sentence you are using for your claim is: An AC verifier MAY use any source for AC revocation status information. No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP server can manage AC revocation status information. Erik observed that the same ASN.1 could be used. Maybe, but a new specification would then be needed to be written. Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past, the major one being in the context of electronic signatures verifications to have a model for certificate verification that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd things. Note also that the concept of Qualified Attribute Certificate is a concept which does not exist at the European level at this time and thus is specific to Germany and I would guess that there is a specification written in German (i.e. not in English). Denis > RFC 3281 says: > > 6. Revocation > > In many environments, the validity period of an AC is less than the > time required to issue and distribute revocation information. > Therefore, short-lived ACs typically do not require revocation > support. However, long-lived ACs and environments where ACs enable > high value transactions MAY require revocation support. > > Two revocation schemes are defined, and the AC issuer should elect > the one that is best suited to the environment in which the AC will > be employed. > > "Never revoke" scheme: > > ACs may be marked so that the relying party understands that no > revocation status information will be made available. The > noRevAvail extension is defined in section 4.3.6, and the > noRevAvail extension MUST be present in the AC to indicate use of > this scheme. > > Where no noRevAvail is present, the AC issuer is implicitly > stating that revocation status checks are supported, and some > revocation method MUST be provided to allow AC verifiers to > establish the revocation status of the AC. > > "Pointer in AC" scheme: > > ACs may "point" to sources of revocation status information, using > either an authorityInfoAccess extension or a crlDistributionPoints > extension within the AC. > > For AC users, the "never revoke" scheme MUST be supported, and the > "pointer in AC" scheme SHOULD be supported. If only the "never > revoke" scheme is supported, then all ACs that do not contain a > noRevAvail extension, MUST be rejected. > > For AC issuers, the "never revoke" scheme MUST be supported. If all > ACs that will ever be issued by that AC issuer, contains a noRevAvail > extension, the "pointer in AC" scheme need not be supported. If any > AC can be issued that does not contain the noRevAvail extension, the > "pointer in AC" scheme MUST be supported. > > An AC MUST NOT contain both a noRevAvail and a "pointer in AC". > > An AC verifier MAY use any source for AC revocation status > information. > > So, my conclusion is that OCSP could support ACs, but I am not aware > of anyone doing so. > > Russ > > > On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote: > >> Hi Denis, >> I did study RFC 6960, especially the ASN.1, and I did not see >> anything that prevents checking of attribute certificates, but >> knowing myself I could miss something. I also know that in PKIX >> terminology a certificate is synonymous to a public-key certificate. >> Kind regards, >> Erik > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------020807000400000002000302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Russ,

I do not believe that your conclusion is correct, since the only sentence you are using for your claim is:
An AC verifier MAY use any source for AC revocation status information.
No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP server can manage AC revocation status information.

Erik observed that the same ASN.1 could be used. Maybe, but a new specification would then be needed to be written.

Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past,
the major one being in the context of electronic signatures verifications to have a model for certificate verification
that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd things.

Note also that the concept of Qualified Attribute Certificate is a concept which does not exist at the European level at this time
and thus is specific to Germany and I would guess that there is a specification written in German (i.e. not in English).

Denis

RFC 3281 says:

6. Revocation

   In many environments, the validity period of an AC is less than the
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not require revocation
   support.  However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   Two revocation schemes are defined, and the AC issuer should elect
   the one that is best suited to the environment in which the AC will
   be employed.

   "Never revoke" scheme:

      ACs may be marked so that the relying party understands that no
      revocation status information will be made available.  The
      noRevAvail extension is defined in section 4.3.6, and the
      noRevAvail extension MUST be present in the AC to indicate use of
      this scheme.

      Where no noRevAvail is present, the AC issuer is implicitly
      stating that revocation status checks are supported, and some
      revocation method MUST be provided to allow AC verifiers to
      establish the revocation status of the AC.

   "Pointer in AC" scheme:

      ACs may "point" to sources of revocation status information, using
      either an authorityInfoAccess extension or a crlDistributionPoints
      extension within the AC.

   For AC users, the "never revoke" scheme MUST be supported, and the
   "pointer in AC" scheme SHOULD be supported.  If only the "never
   revoke" scheme is supported, then all ACs that do not contain a
   noRevAvail extension, MUST be rejected.

   For AC issuers, the "never revoke" scheme MUST be supported.  If all
   ACs that will ever be issued by that AC issuer, contains a noRevAvail
   extension, the "pointer in AC" scheme need not be supported.  If any
   AC can be issued that does not contain the noRevAvail extension, the
   "pointer in AC" scheme MUST be supported.

   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".

   An AC verifier MAY use any source for AC revocation status
   information.

So, my conclusion is that OCSP could support ACs, but I am not aware of anyone doing so.

Russ


On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote:

Hi Denis,
 
I did study RFC 6960, especially the ASN.1, and I did not see anything that prevents checking of attribute certificates, but knowing myself I could miss something. I also know that in PKIX terminology a certificate is synonymous to a public-key certificate.
 
Kind regards,
 
Erik



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------020807000400000002000302-- From nobody Fri Apr 11 08:33:57 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502421A01CF for ; Fri, 11 Apr 2014 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bgLFNLM9q1t for ; Fri, 11 Apr 2014 08:33:53 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE81A069B for ; Fri, 11 Apr 2014 08:33:52 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id ECF071A0096 for ; Fri, 11 Apr 2014 17:33:50 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cb8H0CDaM_vh for ; Fri, 11 Apr 2014 17:33:42 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 5B4521A0097 for ; Fri, 11 Apr 2014 17:33:42 +0200 (CEST) Received: from [10.53.40.204] (port=60067 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WYdSX-0001SE-Lz for ; Fri, 11 Apr 2014 17:33:41 +0200 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 11 Apr 2014 17:33:41 +0200 Message-ID: <53480B54.1020406@secunet.com> Date: Fri, 11 Apr 2014 17:33:40 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr> In-Reply-To: <5348011A.6010902@free.fr> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/MiZWFbKx5CByL1BRVMoPJv-jf1U Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 15:33:55 -0000 > Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past, > the major one being in the context of electronic signatures verifications to have a model for certificate verification > that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd > things. > in general, you are right, German e-signature practices and PKI standards overlap only partially. And the fact that German CAs issuing QC provide status information for ACs over OCSP does not necessarily imply that this practice (and it isn't even based on technical specs but merely on interpretations of the law) conforms to the standards. My impression is that at the time when RFC 2560 was written, the concept of ACs was still considered as future. However, RFC 2560 clearly states that OCSP aims to be a supplement to CRLs: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. and points to RFC 2459. With RFC 3280 superseding RFC 2459, the possibility of having ACs in CRLs was introduced (issuingDistributionPoint), but RFC 2560 was not updated. -- Johannes From nobody Fri Apr 11 10:17:24 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673381A070D for ; Fri, 11 Apr 2014 10:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.262 X-Spam-Level: **** X-Spam-Status: No, score=4.262 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNktlIocze8n for ; Fri, 11 Apr 2014 10:17:20 -0700 (PDT) Received: from scan2.cht.com.tw (scan3.cht.com.tw [202.39.168.43]) by ietfa.amsl.com (Postfix) with ESMTP id 031201A032B for ; Fri, 11 Apr 2014 10:17:19 -0700 (PDT) X-AuditID: 0aa00266-89bfeba000000ba4-9a-5348245af2d5 Received: from HUB6.app.corp.cht.com.tw (unknown [10.172.18.164]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id 18C0D2BC001 for ; Sat, 12 Apr 2014 01:20:26 +0800 (CST) Received: from MBS6.app.corp.cht.com.tw ([fe80::3178:69dd:b794:fa86]) by HUB6.app.corp.cht.com.tw ([fe80::5411:3134:b4a:2940%12]) with mapi id 14.02.0342.003; Sat, 12 Apr 2014 01:17:15 +0800 From: =?iso-2022-jp?B?GyRCMiZKOEA1GyhC?= To: "pkix@ietf.org" Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwEbFzIAAACaOoAAAw+BgAAB8+8AAAGGHQAAE+wZGQAAdl88 Date: Fri, 11 Apr 2014 17:17:14 +0000 Message-ID: <20825998BCB8D84C983674C159E25E753D4BB6AE@mbs6.app.corp.cht.com.tw> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>,<53480B54.1020406@secunet.com> In-Reply-To: <53480B54.1020406@secunet.com> Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [202.39.164.246] Content-Type: multipart/alternative; boundary="_000_20825998BCB8D84C983674C159E25E753D4BB6AEmbs6appcorpchtc_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/Ab4fxSU99RX_BXIBIkczN1JRtow Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:17:22 -0000 --_000_20825998BCB8D84C983674C159E25E753D4BB6AEmbs6appcorpchtc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable To use OCSP for ACs, you have to solve the problem of how an Attribute Auth= ority (AA) can delegate the revocation status response job to an OCSP respo= nder. In section 4.2.2.2 of RFC 6969, it says The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following: - sign the OCSP responses itself, or - explicitly designate this authority to another entity OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request. The problem is that in the cases where an AA is not a CA, the AA can not is= sue an public-key certificate to the OCSP Responder. Therefore, it is not p= ossible for the AA to desiginate OCSP signing delegation. I do not think it= is suitable to let an CA do the delegation on behalf of the AA because the= AA might be a different entity from the CA. Wen-Cheng Wang ________________________________ From: pkix [pkix-bounces@ietf.org] on behalf of Johannes Merkle [johannes.m= erkle@secunet.com] Sent: Friday, April 11, 2014 11:33 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP > Johannes said that it is mandatory in Germany, but Germany has made very = odd things in the past, > the major one being in the context of electronic signatures verifications= to have a model for certificate verification > that is neither compatible with RFC 5280 nor with X.509. So I am not surp= rised that Germany is making additional odd > things. > in general, you are right, German e-signature practices and PKI standards o= verlap only partially. And the fact that German CAs issuing QC provide status information for ACs over OCSP does not= necessarily imply that this practice (and it isn't even based on technical specs but merely on interpretations of the la= w) conforms to the standards. My impression is that at the time when RFC 2560 was written, the concept of= ACs was still considered as future. However, RFC 2560 clearly states that OCSP aims to be a supplement to CRLs: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. and points to RFC 2459. With RFC 3280 superseding RFC 2459, the possibility= of having ACs in CRLs was introduced (issuingDistributionPoint), but RFC 2560 was not updated. -- Johannes _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_20825998BCB8D84C983674C159E25E753D4BB6AEmbs6appcorpchtc_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: quoted-printable

To use OCSP for ACs, you have to solve th= e problem of how an Attribute Authority (AA) can delegate the revocati= on status response job to an OCSP responder.

 

In section 4.2.2.2 of RFC 6969, it says

    

   The key that signs a certificate's status information need = not be the
   same key that signed the certificate.  It is necessary, h= owever, to
   ensure that the entity signing this information is authorized = to do
   so.  Therefore, a certificate's issuer MUST do one of the= following:

   - sign the OCSP responses itself, or

   - explicitly designate this authority to another entity

   OCSP signing delegation SHALL be designated by the inclusio= n of
   id-kp-OCSPSigning in an extended key usage certificate extensi= on
   included in the OCSP response signer's certificate.  This= certificate
   MUST be issued directly by the CA that is identified in the re= quest.

The problem is that in the cases where an=  AA is not a CA, the AA can not issue an public-key certificate to the= OCSP Responder. Therefore, it is not possible for the AA to desiginate OCS= P signing delegation. I do not think it is suitable to let an CA do the delegation on behalf of the AA because the= AA might be a different entity from the CA.

 

Wen-Cheng Wan= g

 =


From: pkix [pkix-bounces@ietf.org] on behalf of J= ohannes Merkle [johannes.merkle@secunet.com]
Sent: Friday, April 11, 2014 11:33 PM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP


> Johannes said that it is mandatory in G= ermany, but Germany has made very odd things in the past,
> the major one being in the context of electronic signatures verificati= ons to have a model for certificate verification
> that is neither compatible with RFC 5280 nor with X.509. So I am not s= urprised that Germany is making additional odd
> things.
>

in general, you are right, German e-signature practices and PKI standards o= verlap only partially. And the fact that
German CAs issuing QC provide status information for ACs over OCSP does not= necessarily imply that this practice (and it
isn't even based on technical specs but merely on interpretations of the la= w) conforms to the standards.

My impression is that at the time when RFC 2560 was written, the concept of= ACs was still considered as future. However,
RFC 2560 clearly states that OCSP aims to be a supplement to CRLs:
   This document specifies a protocol useful in determining the c= urrent
   status of a digital certificate without requiring CRLs.
and points to RFC 2459. With RFC 3280 superseding RFC 2459, the possibility= of having ACs in CRLs was introduced
(issuingDistributionPoint), but RFC 2560 was not updated.
--
Johannes

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/p= kix
--_000_20825998BCB8D84C983674C159E25E753D4BB6AEmbs6appcorpchtc_-- From nobody Fri Apr 11 23:35:16 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6FF1A00B3 for ; Fri, 11 Apr 2014 23:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.81 X-Spam-Level: * X-Spam-Status: No, score=1.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxikSLIdr1gw for ; Fri, 11 Apr 2014 23:35:10 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) by ietfa.amsl.com (Postfix) with ESMTP id BCC4E1A0079 for ; Fri, 11 Apr 2014 23:35:08 -0700 (PDT) Received: from ([62.44.134.252]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id YKV66503 for ; Sat, 12 Apr 2014 08:35:03 +0200 From: "Erik Andersen" To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53480B54.1020406@secunet.com> <20825998BCB8D84C983674C159E25E753D4BB6AE@mbs6.app.corp.cht.com.tw> In-Reply-To: <20825998BCB8D84C983674C159E25E753D4BB6AE@mbs6.app.corp.cht.com.tw> Date: Sat, 12 Apr 2014 08:35:01 +0200 Message-ID: <000901cf5619$57b53be0$071fb3a0$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CF562A.1B40CB00" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG/+lgCTTm0O0fUfLlk3oIfj32E1gFYE2fpAZPvIRgCVTe9lwKsMGH1AyHIIh4Cg2T2dpq/qNhQ Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/Hi2yaGxJzcpYFcyWSkJQx3-ZZlQ Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 06:35:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CF562A.1B40CB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Wen-Cheng Wang - good point. Regards, Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of ??? Sent: Friday, April 11, 2014 7:17 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP To use OCSP for ACs, you have to solve the problem of how an Attribute Authority (AA) can delegate the revocation status response job to an OCSP responder. In section 4.2.2.2 of RFC 6969, it says The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following: - sign the OCSP responses itself, or - explicitly designate this authority to another entity OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request. The problem is that in the cases where an AA is not a CA, the AA can not issue an public-key certificate to the OCSP Responder. Therefore, it is not possible for the AA to desiginate OCSP signing delegation. I do not think it is suitable to let an CA do the delegation on behalf of the AA because the AA might be a different entity from the CA. Wen-Cheng Wang _____ From: pkix [pkix-bounces@ietf.org] on behalf of Johannes Merkle [johannes.merkle@secunet.com] Sent: Friday, April 11, 2014 11:33 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP > Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past, > the major one being in the context of electronic signatures verifications to have a model for certificate verification > that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd > things. > in general, you are right, German e-signature practices and PKI standards overlap only partially. And the fact that German CAs issuing QC provide status information for ACs over OCSP does not necessarily imply that this practice (and it isn't even based on technical specs but merely on interpretations of the law) conforms to the standards. My impression is that at the time when RFC 2560 was written, the concept of ACs was still considered as future. However, RFC 2560 clearly states that OCSP aims to be a supplement to CRLs: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. and points to RFC 2459. With RFC 3280 superseding RFC 2459, the possibility of having ACs in CRLs was introduced (issuingDistributionPoint), but RFC 2560 was not updated. -- Johannes _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_000A_01CF562A.1B40CB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Wen-Cheng Wang – good = point.

 

Regards, Erik

 

From: pkix = [mailto:pkix-bounces@ietf.org] On Behalf Of ???
Sent: = Friday, April 11, 2014 7:17 PM
To: = pkix@ietf.org
Subject: Re: [pkix] ACs an = OCSP

 

To use OCSP = for ACs, you have to solve the problem of how an Attribute = Authority (AA) can delegate the revocation status response job to an = OCSP responder.

 

In section 4.2.2.2 of RFC 6969, it = says

    

   The = key that signs a certificate's status information need not be = the
   same key that signed the certificate.  It is = necessary, however, to
   ensure that the entity signing = this information is authorized to do
   so.  = Therefore, a certificate's issuer MUST do one of the = following:

   - sign = the OCSP responses itself, or

   - = explicitly designate this authority to another = entity

   OCSP = signing delegation SHALL be designated by the inclusion = of
   id-kp-OCSPSigning in an extended key usage = certificate extension
   included in the OCSP response = signer's certificate.  This certificate
   MUST be = issued directly by the CA that is identified in the = request.

The problem is that in the cases where = an AA is not a CA, the AA can not issue an public-key certificate = to the OCSP Responder. Therefore, it is not possible for the AA to = desiginate OCSP signing delegation. I do not think it is suitable to let = an CA do the delegation on behalf of the AA because the AA might be a = different entity from the CA.

 

Wen-Cheng Wang

&nb= sp;


From: pkix [pkix-bounces@ietf.org] on behalf of = Johannes Merkle [johannes.merkle@secunet.com]
Sent: Friday, = April 11, 2014 11:33 PM
To: pkix@ietf.org
Subject: Re: = [pkix] ACs an OCSP

> Johannes said that it is mandatory in = Germany, but Germany has made very odd things in the past,
> the = major one being in the context of electronic signatures verifications to = have a model for certificate verification
> that is neither = compatible with RFC 5280 nor with X.509. So I am not surprised that = Germany is making additional odd
> things.
>

in = general, you are right, German e-signature practices and PKI standards = overlap only partially. And the fact that
German CAs issuing QC = provide status information for ACs over OCSP does not necessarily imply = that this practice (and it
isn't even based on technical specs but = merely on interpretations of the law) conforms to the = standards.

My impression is that at the time when RFC 2560 was = written, the concept of ACs was still considered as future. = However,
RFC 2560 clearly states that OCSP aims to be a supplement to = CRLs:
   This document specifies a protocol useful in = determining the current
   status of a digital certificate = without requiring CRLs.
and points to RFC 2459. With RFC 3280 = superseding RFC 2459, the possibility of having ACs in CRLs was = introduced
(issuingDistributionPoint), but RFC 2560 was not = updated.
--
Johannes

_______________________________________= ________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_000A_01CF562A.1B40CB00-- From nobody Mon Apr 14 04:00:30 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550C31A02AE for ; Mon, 14 Apr 2014 04:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLKHZwXyKL33 for ; Mon, 14 Apr 2014 04:00:27 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 369BE1A0185 for ; Mon, 14 Apr 2014 04:00:27 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 1A6CD1A0097; Mon, 14 Apr 2014 13:00:25 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zKcmgOc1XhzD; Mon, 14 Apr 2014 13:00:16 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 8B9F51A0088; Mon, 14 Apr 2014 13:00:16 +0200 (CEST) Received: from [10.53.40.204] (port=58351 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WZecZ-0002Gu-Qv; Mon, 14 Apr 2014 13:00:15 +0200 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 14 Apr 2014 13:00:15 +0200 Message-ID: <534BBFBF.40206@secunet.com> Date: Mon, 14 Apr 2014 13:00:15 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?546L5paH5q2j?= , "pkix@ietf.org" References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53480B54.1020406@secunet.com> <20825998BCB8D84C983674C159E25E753D4BB6AE@mbs6.app.corp.cht.com.tw> In-Reply-To: <20825998BCB8D84C983674C159E25E753D4BB6AE@mbs6.app.corp.cht.com.tw> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/QFQRKt9k1Xvup20bXZmvWbXLAFM Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:00:28 -0000 王文正 wrote on 11.04.2014 19:17: > The problem is that in the cases where an AA is not a CA, the AA can not issue an public-key certificate to the OCSP > Responder. Therefore, it is not possible for the AA to desiginate OCSP signing delegation. I do not think it is suitable > to let an CA do the delegation on behalf of the AA because the AA might be a different entity from the CA. Right, but there is no reason, why an AA should not be a CA as well, and if it only issues OCSP signer certs. -- Johannes From nobody Mon Apr 14 08:08:21 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1891A04CA for ; Mon, 14 Apr 2014 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.763 X-Spam-Level: ** X-Spam-Status: No, score=2.763 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZqFMPJlekUr for ; Mon, 14 Apr 2014 08:08:14 -0700 (PDT) Received: from scan1.cht.com.tw (scan1.cht.com.tw [202.39.168.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1F91A04BA for ; Mon, 14 Apr 2014 08:08:14 -0700 (PDT) X-AuditID: 0aa00268-827fdba000003326-e9-534bfa2b72ef Received: from HUB4.app.corp.cht.com.tw (unknown [10.172.18.168]) by scan1.cht.com.tw (Symantec Mail Security) with ESMTP id B615F154263 for ; Mon, 14 Apr 2014 23:09:31 +0800 (CST) Received: from MBS6.app.corp.cht.com.tw ([fe80::3178:69dd:b794:fa86]) by HUB4.app.corp.cht.com.tw ([fe80::f8db:4064:82dd:2fdb%12]) with mapi id 14.02.0342.003; Mon, 14 Apr 2014 23:08:10 +0800 From: =?utf-8?B?546L5paH5q2j?= To: "pkix@ietf.org" Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9X81ikGSAPSCCkRAaVwjME5VKUOw== Date: Mon, 14 Apr 2014 15:08:09 +0000 Message-ID: <9v7cqgp80k2yupgfsd8jod1p.1397487206810@email.android.com> Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9v7cqgp80k2yupgfsd8jod1p1397487206810emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/2NN-oUx_Nxnh5gs1ElmHqp-dn9Y Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: =?utf-8?B?546L5paH5q2j?= List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:08:18 -0000 --_000_9v7cqgp80k2yupgfsd8jod1p1397487206810emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQsIGFuIEFBIG1pZ2h0IGJlIGEgQ0EgYXMgd2VsbCwgYnV0IHRoaXMgaXMgbm90IGFsd2F5 cyB0aGUgY2FzZS4gSWYgYW4gQUEgd2FudHMgdG8gbGVnYWxseSBhY3QgYXMgYSBDQSwgaXRzIGNl cnRpZmljYXRlIG11c3QgY29udGFpbiB0aGUgQmFzaWNDb25zdHJhaW5zIGV4dGVuc2lvbiB3aXRo IGNBPXRydWUgYW5kIGl0cyBLZXlVc2FnZSBFeHRlbnNpb24gbXVzdCBhdCBsZWFzdCBjb250YWlu IGtleUNlcnRTaWduIGJpdC4gT3RoZXJ3aXNlLCBPQ1NQIHJlc3BvbmRlciBjZXJ0aWZpY2F0ZSBz aWduZWQgYnkgdGhlIEFBIHdpbGwgYmUgcmVqZWN0ZWQgYnkgUkZDLTUyODAgY29tcGxpYW50IGNl cnRpZmljYXRlIHBhdGggdmFsaWRhdG9ycy4NCg0KV2VuLUNoZW5nIFdhbmcNCg0KDQoNCi0tLS0t LS0tIOWOn+Wni+mDteS7tiAtLS0tLS0tLQ0K6Ieq77yaIEpvaGFubmVzIE1lcmtsZSA8am9oYW5u ZXMubWVya2xlQHNlY3VuZXQuY29tPg0K5pel5pyf77yaDQroh7PvvJog546L5paH5q2jIDx3Y3dh bmdAY2h0LmNvbS50dz4scGtpeEBpZXRmLm9yZw0K5Li75peo77yaIFJlOiBbcGtpeF0gQUNzIGFu IE9DU1ANCg0KDQoNClJpZ2h0LCBidXQgdGhlcmUgaXMgbm8gcmVhc29uLCB3aHkgYW4gQUEgc2hv dWxkIG5vdCBiZSBhIENBIGFzIHdlbGwsIGFuZCBpZiBpdCBvbmx5IGlzc3VlcyBPQ1NQIHNpZ25l ciBjZXJ0cy4NCg0KLS0NCkpvaGFubmVzDQo= --_000_9v7cqgp80k2yupgfsd8jod1p1397487206810emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <12438DD2CC5DE245BE0F8746B1C17B54@cht.com.tw> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5SaWdodCwg YW4gQUEgbWlnaHQgYmUgYSBDQSBhcyB3ZWxsLCBidXQgdGhpcyBpcyBub3QgYWx3YXlzIHRoZSBj YXNlLiBJZiBhbiBBQSB3YW50cyB0byBsZWdhbGx5IGFjdCBhcyBhIENBLCBpdHMgY2VydGlmaWNh dGUgbXVzdCBjb250YWluIHRoZSBCYXNpY0NvbnN0cmFpbnMgZXh0ZW5zaW9uIHdpdGggY0E9dHJ1 ZSBhbmQgaXRzIEtleVVzYWdlIEV4dGVuc2lvbiBtdXN0IGF0IGxlYXN0IGNvbnRhaW4ga2V5Q2Vy dFNpZ24gYml0LiBPdGhlcndpc2UsDQogT0NTUCByZXNwb25kZXIgY2VydGlmaWNhdGUgc2lnbmVk IGJ5IHRoZSBBQSB3aWxsIGJlIHJlamVjdGVkIGJ5IFJGQy01MjgwIGNvbXBsaWFudCBjZXJ0aWZp Y2F0ZSBwYXRoIHZhbGlkYXRvcnMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XZW4t Q2hlbmcgV2FuZzwvZGl2Pg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0g5Y6f5aeL6YO15Lu2 IC0tLS0tLS0tPGJyPg0K6Ieq77yaIEpvaGFubmVzIE1lcmtsZSAmbHQ7am9oYW5uZXMubWVya2xl QHNlY3VuZXQuY29tJmd0OyA8YnI+DQrml6XmnJ/vvJogPGJyPg0K6Iez77yaIOeOi+aWh+atoyAm bHQ7d2N3YW5nQGNodC5jb20udHcmZ3Q7LHBraXhAaWV0Zi5vcmcgPGJyPg0K5Li75peo77yaIFJl OiBbcGtpeF0gQUNzIGFuIE9DU1AgPGJyPg0KPGJyPg0KPGJyPg0KPGZvbnQgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4N ClJpZ2h0LCBidXQgdGhlcmUgaXMgbm8gcmVhc29uLCB3aHkgYW4gQUEgc2hvdWxkIG5vdCBiZSBh IENBIGFzIHdlbGwsIGFuZCBpZiBpdCBvbmx5IGlzc3VlcyBPQ1NQIHNpZ25lciBjZXJ0cy48YnI+ DQo8YnI+DQotLSA8YnI+DQpKb2hhbm5lczxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9v7cqgp80k2yupgfsd8jod1p1397487206810emailandroidcom_-- From nobody Tue Apr 15 07:06:05 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C351A02CE for ; Tue, 15 Apr 2014 05:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-J4faUW-YiN; Tue, 15 Apr 2014 05:08:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B051A02BB; Tue, 15 Apr 2014 05:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: housley@vigilsec.com, draft-housley-pkix-oids@tools.ietf.org, pkix@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415120850.26270.59477.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 05:08:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/LZi_f5pKVRR_Dv6b4aSIfwN8g3k X-Mailman-Approved-At: Tue, 15 Apr 2014 07:06:03 -0700 Subject: [pkix] ID Tracker State Update Notice: X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 12:08:55 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-housley-pkix-oids/ From nobody Thu Apr 17 04:35:30 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD351A0117; Thu, 17 Apr 2014 04:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G-rJPN_S7xP; Thu, 17 Apr 2014 04:35:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1E21A010F; Thu, 17 Apr 2014 04:35:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417113521.18477.95663.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 04:35:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/BFmk5L6okIvBtE82I3L5gmYvTd8 Cc: pkix@ietf.org, draft-housley-pkix-oids@tools.ietf.org Subject: [pkix] Adrian Farrel's No Objection on draft-housley-pkix-oids-02: (with COMMENT) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 11:35:27 -0000 Adrian Farrel has entered the following ballot position for draft-housley-pkix-oids-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-housley-pkix-oids/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate that the process here is a bit complicated because the arc is transitioning from the PKIX WG to IANA. That means some codepoints are limbotomised (caught in the gap created by the transition) in that the DE has not had a chance to pronounce on them and no IETF-approved document records them, yet they need to be captured in the new registry. I think it would be good to call these out explicitly (yes they are present in the lists in Section 3, but there is no explanation) so that we have a record that the WG has already approved them. Part of the issue here is that the relevant documents are not PKIX WG documents. Furthermore, the documents do not appear to have satisfactory IANA considerations sections. Obviously, this document cannot fix those other documents, but it would be good to include a section (e.g. 2.1) describing "Allocations Already Approved by the PKIX Working Group". I believe that this would also serve to address IANA's questions about the relationship with draft-housley-pkix-test-oids (although not their question about 31 != 33). The related I-Ds in question are: - draft-jabley-dnssec-trust-anchor-08 [ID-Abley] - draft-ietf-sidr-bgpsec-pki-profiles [ID-BGPSEC] - draft-housley-pkix-test-oids [ID-Housley] (slightly different category because it is in the RFC editor queue) From nobody Thu Apr 17 13:46:29 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E512D1A01A5 for ; Thu, 17 Apr 2014 13:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkcLXqyQv7Id for ; Thu, 17 Apr 2014 13:46:25 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8E84C1A0045 for ; Thu, 17 Apr 2014 13:46:24 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 17 Apr 2014 16:46:12 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 17 Apr 2014 16:46:20 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s3HKkInC014138 for ; Thu, 17 Apr 2014 16:46:18 -0400 Message-ID: <53503D9A.1060101@nist.gov> Date: Thu, 17 Apr 2014 16:46:18 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr> In-Reply-To: <5348011A.6010902@free.fr> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/5zzJhsdnim-KYrWKOmCOKSJD03Y Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:46:27 -0000
Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical.

4.  Attribute Certificate Profile

4.3.  Extensions

4.3.4.  Authority Information Access

   The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be
   used to assist the AC verifier in checking the revocation status of
   the AC.  Support for the id-ad-caIssuers accessMethod is OPTIONAL by
   this profile since AC chains are not expected.

   The following accessMethod is used to indicate that revocation status
   checking is provided for this AC, using the Online Certificate Status
   Protocol (OCSP) defined in [OCSP]:

      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   The accessLocation MUST contain a URI, and the URI MUST contain an
   HTTP URL [HTTP-URL] that specifies the location of an OCSP responder.
   The AC issuer MUST, of course, maintain an OCSP responder at this
   location.

      name           id-ce-authorityInfoAccess
      OID            { id-pe 1 }
      syntax         AuthorityInfoAccessSyntax
      criticality    MUST be FALSE


On 04/11/2014 10:50 AM, Denis wrote:
Hello Russ,

I do not believe that your conclusion is correct, since the only sentence you are using for your claim is:
An AC verifier MAY use any source for AC revocation status information.
No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP server can manage AC revocation status information.

Erik observed that the same ASN.1 could be used. Maybe, but a new specification would then be needed to be written.

Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past,
the major one being in the context of electronic signatures verifications to have a model for certificate verification
that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd things.

Note also that the concept of Qualified Attribute Certificate is a concept which does not exist at the European level at this time
and thus is specific to Germany and I would guess that there is a specification written in German (i.e. not in English).

Denis

RFC 3281 says:

6. Revocation

   In many environments, the validity period of an AC is less than the
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not require revocation
   support.  However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   Two revocation schemes are defined, and the AC issuer should elect
   the one that is best suited to the environment in which the AC will
   be employed.

   "Never revoke" scheme:

      ACs may be marked so that the relying party understands that no
      revocation status information will be made available.  The
      noRevAvail extension is defined in section 4.3.6, and the
      noRevAvail extension MUST be present in the AC to indicate use of
      this scheme.

      Where no noRevAvail is present, the AC issuer is implicitly
      stating that revocation status checks are supported, and some
      revocation method MUST be provided to allow AC verifiers to
      establish the revocation status of the AC.

   "Pointer in AC" scheme:

      ACs may "point" to sources of revocation status information, using
      either an authorityInfoAccess extension or a crlDistributionPoints
      extension within the AC.

   For AC users, the "never revoke" scheme MUST be supported, and the
   "pointer in AC" scheme SHOULD be supported.  If only the "never
   revoke" scheme is supported, then all ACs that do not contain a
   noRevAvail extension, MUST be rejected.

   For AC issuers, the "never revoke" scheme MUST be supported.  If all
   ACs that will ever be issued by that AC issuer, contains a noRevAvail
   extension, the "pointer in AC" scheme need not be supported.  If any
   AC can be issued that does not contain the noRevAvail extension, the
   "pointer in AC" scheme MUST be supported.

   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".

   An AC verifier MAY use any source for AC revocation status
   information.

So, my conclusion is that OCSP could support ACs, but I am not aware of anyone doing so.

Russ


On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote:

Hi Denis,
 
I did study RFC 6960, especially the ASN.1, and I did not see anything that prevents checking of attribute certificates, but knowing myself I could miss something. I also know that in PKIX terminology a certificate is synonymous to a public-key certificate.
 
Kind regards,
 
Erik
From nobody Thu Apr 17 18:49:04 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940461A0141 for ; Thu, 17 Apr 2014 18:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.363 X-Spam-Level: ** X-Spam-Status: No, score=2.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly95L-lG5Q3R for ; Thu, 17 Apr 2014 18:48:52 -0700 (PDT) Received: from scan2.cht.com.tw (scan2.cht.com.tw [202.39.168.16]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC11A00FC for ; Thu, 17 Apr 2014 18:48:51 -0700 (PDT) X-AuditID: 0aa00267-872d6ba0000008df-d8-53508566acf3 Received: from HUB3.app.corp.cht.com.tw (unknown [10.172.18.167]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id ED54E154238 for ; Fri, 18 Apr 2014 09:52:38 +0800 (CST) Received: from MBS6.app.corp.cht.com.tw ([fe80::3178:69dd:b794:fa86]) by HUB3.app.corp.cht.com.tw ([fe80::8cc5:ca30:74c5:aafe%12]) with mapi id 14.02.0342.003; Fri, 18 Apr 2014 09:48:46 +0800 From: =?iso-2022-jp?B?GyRCMiZKOEA1GyhC?= To: "pkix@ietf.org" Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwEbFzIAAACaOoAAAw+BgAAB8+8AATow5QAAGsSZCgAAj4Rj Date: Fri, 18 Apr 2014 01:48:45 +0000 Message-ID: <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>,<53503D9A.1060101@nist.gov> In-Reply-To: <53503D9A.1060101@nist.gov> Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [202.39.164.245] Content-Type: multipart/alternative; boundary="_000_20825998BCB8D84C983674C159E25E753D4C1E65mbs6appcorpchtc_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/wCZ4QoOEdQmSyW1Hu3bYjF1_Jcs Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 01:48:56 -0000 --_000_20825998BCB8D84C983674C159E25E753D4C1E65mbs6appcorpchtc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess ex= tension can be used to indicate OCSP is provided for that AC, OCSP is actua= lly can not be used for ACs beacuse it is not possible for the AA to issue = an public-key certificate to the OCSP Responder for delegating the revocati= on status response job. Wen-Cheng Wang ________________________________ From: pkix [pkix-bounces@ietf.org] on behalf of David A. Cooper [david.coop= er@nist.gov] Sent: Friday, April 18, 2014 4:46 AM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambigu= ous. The text in Section 4.3.4 of RFC 3281 is nearly identical. 4. Attribute Certificate Profile 4.3. Extensions 4.3.4. Authority Information Access The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by this profile since AC chains are not expected. The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the Online Certificate Status Protocol (OCSP) defined in [OCSP]: id-ad-ocsp OBJECT IDENTIFIER ::=3D { id-ad 1 } The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location. name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE --_000_20825998BCB8D84C983674C159E25E753D4C1E65mbs6appcorpchtc_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: <53DF66F1DF8071418A435469D5DB2A6E@cht.com.tw> Content-Transfer-Encoding: quoted-printable

Although both RFC 3281 and RFC 5755 speci= fy that the authorityInfoAccess extension can be used to indicate OCSP= is provided for that AC, OCSP is actually can not be used for ACs bea= cuse it is not possible for the AA to issue an public-key certificate to the OCSP Responder for delegating the revocat= ion status response job.

 

Wen-Cheng Wang
 

From: pkix [pkix-bounces@i= etf.org] on behalf of David A. Cooper [david.cooper@nist.gov]
Sent: Friday, April 18, 2014 4:46 AM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

Here is text = from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text= in Section 4.3.4 of RFC 3281 is nearly identical.

4. =
 Attribute Certificate Profile=0A=
=0A=
<=
span class=3D"m_h">4.3.  Extensions=0A=
=0A=
4.3.4.  Authority Information Access=0A=
=0A=
   The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be=0A=
   used to assist the AC verifier in checking the revocation status of=0A=
   the AC.  Support for the id-ad-caIssuers accessMethod is OPTIONAL by=0A=
   this profile since AC chains are not expected.=0A=
=0A=
   The following accessMethod is used to indicate that revocation status=0A=
   checking is provided for this AC, using the Online Certificate Status=0A=
   Protocol (OCSP) defined in [OCSP]:=0A=
=0A=
      id-ad-ocsp OBJECT IDENTIFIER ::=3D { id-ad 1 }=0A=
=0A=
   The accessLocation MUST contain a URI, and the URI MUST contain an=0A=
   HTTP URL [HTTP-URL] that specifies the location of an OCSP responder.=0A=
   The AC issuer MUST, of course, maintain an OCSP responder at this=0A=
   location.=0A=
=0A=
      name           id-ce-authorityInfoAccess=0A=
      OID            { id-pe 1 }=0A=
      syntax         AuthorityInfoAccessSyntax=0A=
      criticality    MUST be FALSE
--_000_20825998BCB8D84C983674C159E25E753D4C1E65mbs6appcorpchtc_-- From nobody Fri Apr 18 01:50:43 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144FB1A02AE for ; Fri, 18 Apr 2014 01:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inJUfQCzr_-d for ; Fri, 18 Apr 2014 01:50:33 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by ietfa.amsl.com (Postfix) with ESMTP id 13AB31A0101 for ; Fri, 18 Apr 2014 01:50:33 -0700 (PDT) Received: from [192.168.0.12] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0296C82F23 for ; Fri, 18 Apr 2014 10:50:21 +0200 (CEST) Message-ID: <5350E756.2070004@free.fr> Date: Fri, 18 Apr 2014 10:50:30 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr> <53503D9A.1060101@nist.gov> In-Reply-To: <53503D9A.1060101@nist.gov> Content-Type: multipart/alternative; boundary="------------020207090903080904020807" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/U8LRW7b6fHad0iEW1hqz5uqSKnU Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 08:50:38 -0000 This is a multi-part message in MIME format. --------------020207090903080904020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, This is quite interesting. RFC 6960 was produced after RFC 5755 and it is quite curious that RFC 6960 does not say anything about it. One of the problem with these RFCs is that they define data structures, but do not say how to use them. In particular if you get some data back from that URL in the case of an AC , how do you verify that the response is correctly signed ? This is not said, so interoperability is only a dream. Maybe all of this is only an hypothetical case. A long time ago, I made presentation at the RSA Security Conference in San Francisco with the following title: Why are Attribute Certificates not yet in use today ? Ten years after that presentation, the situation has not much changed. One among the many reasons, is that among the three main options for linking a certificate to "something else", two of them are insecure. Denis > Here is text from RFC 5755 (which obsoleted RFC 3281) that is more > unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical. > > 4. Attribute Certificate Profile > > 4.3. Extensions > > 4.3.4. Authority Information Access > > The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be > used to assist the AC verifier in checking the revocation status of > the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by > this profile since AC chains are not expected. > > The following accessMethod is used to indicate that revocation status > checking is provided for this AC, using the Online Certificate Status > Protocol (OCSP) defined in [OCSP]: > > id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } > > The accessLocation MUST contain a URI, and the URI MUST contain an > HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. > The AC issuer MUST, of course, maintain an OCSP responder at this > location. > > name id-ce-authorityInfoAccess > OID { id-pe 1 } > syntax AuthorityInfoAccessSyntax > criticality MUST be FALSE > > > On 04/11/2014 10:50 AM, Denis wrote: >> Hello Russ, >> >> I do not believe that your conclusion is correct, since the only >> sentence you are using for your claim is: >> >> An AC verifier MAY use any source for AC revocation status >> information. >> >> No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP >> server can manage AC revocation status information. >> >> Erik observed that the same ASN.1 could be used. Maybe, but a new >> specification would then be needed to be written. >> >> Johannes said that it is mandatory in Germany, but Germany has made >> very odd things in the past, >> the major one being in the context of electronic signatures >> verifications to have a model for certificate verification >> that is neither compatible with RFC 5280 nor with X.509. So I am not >> surprised that Germany is making additional odd things. >> >> Note also that the concept of Qualified Attribute Certificate is a >> concept which does not exist at the European level at this time >> and thus is specific to Germany and I would guess that there is a >> specification written in German (i.e. not in English). >> >> Denis >> >>> RFC 3281 says: >>> >>> 6. Revocation >>> >>> In many environments, the validity period of an AC is less than the >>> time required to issue and distribute revocation information. >>> Therefore, short-lived ACs typically do not require revocation >>> support. However, long-lived ACs and environments where ACs enable >>> high value transactions MAY require revocation support. >>> >>> Two revocation schemes are defined, and the AC issuer should elect >>> the one that is best suited to the environment in which the AC will >>> be employed. >>> >>> "Never revoke" scheme: >>> >>> ACs may be marked so that the relying party understands that no >>> revocation status information will be made available. The >>> noRevAvail extension is defined in section 4.3.6, and the >>> noRevAvail extension MUST be present in the AC to indicate use of >>> this scheme. >>> >>> Where no noRevAvail is present, the AC issuer is implicitly >>> stating that revocation status checks are supported, and some >>> revocation method MUST be provided to allow AC verifiers to >>> establish the revocation status of the AC. >>> >>> "Pointer in AC" scheme: >>> >>> ACs may "point" to sources of revocation status information, using >>> either an authorityInfoAccess extension or a crlDistributionPoints >>> extension within the AC. >>> >>> For AC users, the "never revoke" scheme MUST be supported, and the >>> "pointer in AC" scheme SHOULD be supported. If only the "never >>> revoke" scheme is supported, then all ACs that do not contain a >>> noRevAvail extension, MUST be rejected. >>> >>> For AC issuers, the "never revoke" scheme MUST be supported. If all >>> ACs that will ever be issued by that AC issuer, contains a noRevAvail >>> extension, the "pointer in AC" scheme need not be supported. If any >>> AC can be issued that does not contain the noRevAvail extension, the >>> "pointer in AC" scheme MUST be supported. >>> >>> An AC MUST NOT contain both a noRevAvail and a "pointer in AC". >>> >>> An AC verifier MAY use any source for AC revocation status >>> information. >>> >>> So, my conclusion is that OCSP could support ACs, but I am not aware >>> of anyone doing so. >>> >>> Russ >>> >>> >>> On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote: >>> >>>> Hi Denis, >>>> I did study RFC 6960, especially the ASN.1, and I did not see >>>> anything that prevents checking of attribute certificates, but >>>> knowing myself I could miss something. I also know that in PKIX >>>> terminology a certificate is synonymous to a public-key certificate. >>>> Kind regards, >>>> Erik > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------020207090903080904020807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
David,

This is quite interesting.

RFC 6960 was produced after RFC 5755 and it is quite curious that RFC 6960 does not say anything about it.

One of the problem with these RFCs is that they define data structures, but do not say how to use them.
In particular if you get some data back from that URL in the case of an AC , how do you verify that the response is correctly signed ?
This is not said, so interoperability is only a dream.

Maybe all of this is only an hypothetical case.  A long time ago, I made presentation at the RSA Security Conference in San Francisco
with the following title:
Why are Attribute Certificates not yet in use today ?
Ten years after that presentation, the situation has not much changed.

One among the many reasons, is that among the three main options for linking a certificate to "something else", two of them are insecure.

Denis

Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical.

4.  Attribute Certificate Profile

4.3.  Extensions

4.3.4.  Authority Information Access

   The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be
   used to assist the AC verifier in checking the revocation status of
   the AC.  Support for the id-ad-caIssuers accessMethod is OPTIONAL by
   this profile since AC chains are not expected.

   The following accessMethod is used to indicate that revocation status
   checking is provided for this AC, using the Online Certificate Status
   Protocol (OCSP) defined in [OCSP]:

      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   The accessLocation MUST contain a URI, and the URI MUST contain an
   HTTP URL [HTTP-URL] that specifies the location of an OCSP responder.
   The AC issuer MUST, of course, maintain an OCSP responder at this
   location.

      name           id-ce-authorityInfoAccess
      OID            { id-pe 1 }
      syntax         AuthorityInfoAccessSyntax
      criticality    MUST be FALSE


On 04/11/2014 10:50 AM, Denis wrote:
Hello Russ,

I do not believe that your conclusion is correct, since the only sentence you are using for your claim is:
An AC verifier MAY use any source for AC revocation status information.
No text (i.e. neither RFC 2560 or RFC 6960) states that an OCSP server can manage AC revocation status information.

Erik observed that the same ASN.1 could be used. Maybe, but a new specification would then be needed to be written.

Johannes said that it is mandatory in Germany, but Germany has made very odd things in the past,
the major one being in the context of electronic signatures verifications to have a model for certificate verification
that is neither compatible with RFC 5280 nor with X.509. So I am not surprised that Germany is making additional odd things.

Note also that the concept of Qualified Attribute Certificate is a concept which does not exist at the European level at this time
and thus is specific to Germany and I would guess that there is a specification written in German (i.e. not in English).

Denis

RFC 3281 says:

6. Revocation

   In many environments, the validity period of an AC is less than the
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not require revocation
   support.  However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   Two revocation schemes are defined, and the AC issuer should elect
   the one that is best suited to the environment in which the AC will
   be employed.

   "Never revoke" scheme:

      ACs may be marked so that the relying party understands that no
      revocation status information will be made available.  The
      noRevAvail extension is defined in section 4.3.6, and the
      noRevAvail extension MUST be present in the AC to indicate use of
      this scheme.

      Where no noRevAvail is present, the AC issuer is implicitly
      stating that revocation status checks are supported, and some
      revocation method MUST be provided to allow AC verifiers to
      establish the revocation status of the AC.

   "Pointer in AC" scheme:

      ACs may "point" to sources of revocation status information, using
      either an authorityInfoAccess extension or a crlDistributionPoints
      extension within the AC.

   For AC users, the "never revoke" scheme MUST be supported, and the
   "pointer in AC" scheme SHOULD be supported.  If only the "never
   revoke" scheme is supported, then all ACs that do not contain a
   noRevAvail extension, MUST be rejected.

   For AC issuers, the "never revoke" scheme MUST be supported.  If all
   ACs that will ever be issued by that AC issuer, contains a noRevAvail
   extension, the "pointer in AC" scheme need not be supported.  If any
   AC can be issued that does not contain the noRevAvail extension, the
   "pointer in AC" scheme MUST be supported.

   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".

   An AC verifier MAY use any source for AC revocation status
   information.

So, my conclusion is that OCSP could support ACs, but I am not aware of anyone doing so.

Russ


On Apr 11, 2014, at 8:26 AM, Erik Andersen wrote:

Hi Denis,
 
I did study RFC 6960, especially the ASN.1, and I did not see anything that prevents checking of attribute certificates, but knowing myself I could miss something. I also know that in PKIX terminology a certificate is synonymous to a public-key certificate.
 
Kind regards,
 
Erik


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------020207090903080904020807-- From nobody Fri Apr 18 01:58:29 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B773F1A001B for ; Fri, 18 Apr 2014 01:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQqkeQgBuJkm for ; Fri, 18 Apr 2014 01:58:26 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A51A0140 for ; Fri, 18 Apr 2014 01:58:21 -0700 (PDT) Received: from [192.168.0.12] (unknown [88.182.125.39]) by smtp4-g21.free.fr (Postfix) with ESMTP id CE5374C8DE4 for ; Fri, 18 Apr 2014 10:58:09 +0200 (CEST) Message-ID: <5350E92B.9000106@free.fr> Date: Fri, 18 Apr 2014 10:58:19 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pkix@ietf.org References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw> In-Reply-To: <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw> Content-Type: multipart/alternative; boundary="------------030002020407020006090906" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/eAZEKrZPdIT2CUmPpoDjTqan0Y8 Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 08:58:27 -0000 This is a multi-part message in MIME format. --------------030002020407020006090906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wen-Cheng, One one side your right: this would be the "normal" way to do it, in order to allow to use an automatic and an interoperable mechanism. One the other side, there is also the possibility to have a "local configuration", but it is not an automatic nor an interoperable mechanism. So it is unscalable. Using OCSP for ACs has not been fully thought, but only those using ACs would care. Who really cares ? Denis > Although both RFC 3281 and RFC 5755 specify that the > authorityInfoAccess extension can be used to indicate OCSP is provided > for that AC, OCSP is actually can not be used for ACs beacuse it is > not possible for the AA to issue an public-key certificate to the OCSP > Responder for delegating the revocation status response job. > > Wen-Cheng Wang > ------------------------------------------------------------------------ > *From:* pkix [pkix-bounces@ietf.org] on behalf of David A. Cooper > [david.cooper@nist.gov] > *Sent:* Friday, April 18, 2014 4:46 AM > *To:* pkix@ietf.org > *Subject:* Re: [pkix] ACs an OCSP > > Here is text from RFC 5755 (which obsoleted RFC 3281) that is more > unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical. > > 4. Attribute Certificate Profile > > 4.3. Extensions > > 4.3.4. Authority Information Access > > The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be > used to assist the AC verifier in checking the revocation status of > the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by > this profile since AC chains are not expected. > > The following accessMethod is used to indicate that revocation status > checking is provided for this AC, using the Online Certificate Status > Protocol (OCSP) defined in [OCSP]: > > id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } > > The accessLocation MUST contain a URI, and the URI MUST contain an > HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. > The AC issuer MUST, of course, maintain an OCSP responder at this > location. > > name id-ce-authorityInfoAccess > OID { id-pe 1 } > syntax AuthorityInfoAccessSyntax > criticality MUST be FALSE > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------030002020407020006090906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Wen-Cheng,

One one side your right: this would be the "normal" way to do it, in order to allow to use an automatic and an interoperable mechanism.
 
One the other side, there is also the possibility to have a "local configuration", but it is not an automatic nor an interoperable mechanism. So it is unscalable.

Using OCSP for ACs has not been fully thought, but only those using ACs would care. Who really cares ?

Denis

Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess extension can be used to indicate OCSP is provided for that AC, OCSP is actually can not be used for ACs beacuse it is not possible for the AA to issue an public-key certificate to the OCSP Responder for delegating the revocation status response job.

 

Wen-Cheng Wang
 

From: pkix [pkix-bounces@ietf.org] on behalf of David A. Cooper [david.cooper@nist.gov]
Sent: Friday, April 18, 2014 4:46 AM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical.

4.  Attribute Certificate Profile

4.3.  Extensions

4.3.4.  Authority Information Access

   The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be
   used to assist the AC verifier in checking the revocation status of
   the AC.  Support for the id-ad-caIssuers accessMethod is OPTIONAL by
   this profile since AC chains are not expected.

   The following accessMethod is used to indicate that revocation status
   checking is provided for this AC, using the Online Certificate Status
   Protocol (OCSP) defined in [OCSP]:

      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   The accessLocation MUST contain a URI, and the URI MUST contain an
   HTTP URL [HTTP-URL] that specifies the location of an OCSP responder.
   The AC issuer MUST, of course, maintain an OCSP responder at this
   location.

      name           id-ce-authorityInfoAccess
      OID            { id-pe 1 }
      syntax         AuthorityInfoAccessSyntax
      criticality    MUST be FALSE


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------030002020407020006090906-- From nobody Fri Apr 18 05:25:34 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7C1A01A8 for ; Fri, 18 Apr 2014 05:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNBFISNAAdoZ for ; Fri, 18 Apr 2014 05:25:30 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9B11A01D9 for ; Fri, 18 Apr 2014 05:25:28 -0700 (PDT) Received: from ([62.44.135.225]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id EQR71820 for ; Fri, 18 Apr 2014 14:25:20 +0200 From: "Erik Andersen" To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw> <5350E92B.9000106@free.fr> In-Reply-To: <5350E92B.9000106@free.fr> Date: Fri, 18 Apr 2014 14:25:17 +0200 Message-ID: <002601cf5b01$4609b550$d21d1ff0$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CF5B12.099BAD10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG/+lgCTTm0O0fUfLlk3oIfj32E1gFYE2fpAZPvIRgCVTe9lwKsMGH1Aileu/8DNtyldgLhHw9UmrSUIbA= Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/agewe4DpCDpKf3Af_DQH2m1VHZQ Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 12:25:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0027_01CF5B12.099BAD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Whether ACs are of interest is an interesting question. In smart grid security, role-based access control (RBAC) seems for some reason as an important aspect. The lifetime of a role may be shorter than the life of a public-key certificate. An AC is then seen as a temporary extension to a public-key certificate. SAML is not considered here. Validation could be a major performance issue in a constrained environment. Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Friday, April 18, 2014 10:58 AM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Wen-Cheng, One one side your right: this would be the "normal" way to do it, in order to allow to use an automatic and an interoperable mechanism. One the other side, there is also the possibility to have a "local configuration", but it is not an automatic nor an interoperable mechanism. So it is unscalable. Using OCSP for ACs has not been fully thought, but only those using ACs would care. Who really cares ? Denis Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess extension can be used to indicate OCSP is provided for that AC, OCSP is actually can not be used for ACs beacuse it is not possible for the AA to issue an public-key certificate to the OCSP Responder for delegating the revocation status response job. Wen-Cheng Wang _____ From: pkix [pkix-bounces@ietf.org ] on behalf of David A. Cooper [david.cooper@nist.gov ] Sent: Friday, April 18, 2014 4:46 AM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Section 4.3.4 of RFC 3281 is nearly identical. 4. Attribute Certificate Profile 4.3. Extensions 4.3.4. Authority Information Access The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by this profile since AC chains are not expected. The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the Online Certificate Status Protocol (OCSP) defined in [OCSP]: id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location. name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0027_01CF5B12.099BAD10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Whether ACs are of interest is an = interesting question.

 

In smart grid security, role-based access = control (RBAC) seems for some reason as an important aspect. The = lifetime of a role may be shorter than the life of a public-key = certificate. An AC is then seen as a temporary extension to a public-key = certificate.

 

SAML is not considered = here.

 

Validation could be a major performance = issue in a constrained environment.

 

Erik

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of = Denis
Sent: Friday, April 18, 2014 10:58 AM
To: = pkix@ietf.org
Subject: Re: [pkix] ACs an = OCSP

 

Wen-Cheng,

One one side your = right: this would be the "normal" way to do it, in order to = allow to use an automatic and an interoperable = mechanism.
 
One the other side, there is also the = possibility to have a "local configuration", but it is not an = automatic nor an interoperable mechanism. So it is = unscalable.

Using OCSP for ACs has not been fully thought, but = only those using ACs would care. Who really cares = ?

Denis

Although both RFC = 3281 and RFC 5755 specify that the authorityInfoAccess extension = can be used to indicate OCSP is provided for that AC, OCSP is = actually can not be used for ACs beacuse it is not possible for the = AA to issue an public-key certificate to the OCSP Responder for = delegating the revocation status response job.

 

Wen-Cheng Wang

 


From: pkix [pkix-bounces@ietf.org] on = behalf of David A. Cooper [david.cooper@nist.gov]
Se= nt: Friday, April 18, 2014 4:46 AM
To: pkix@ietf.org
Subject: Re: = [pkix] ACs an OCSP

Here is text = from RFC 5755 (which obsoleted RFC 3281) that is more unambiguous. The = text in Section 4.3.4 of RFC 3281 is nearly identical.

4.  Attribute Certificate =
Profile
 
4.3.  Extensions
 
4.3.4.  Authority Information =
Access
 
 &nbs=
p; The authorityInfoAccess extension, as defined in [PKIXPROF], MAY =
be
   used to assist the AC verifier in =
checking the revocation status of
   the =
AC.  Support for the id-ad-caIssuers accessMethod is OPTIONAL =
by
   this profile since AC chains are =
not =
expected.
 
   =
The following accessMethod is used to indicate that revocation =
status
   checking is provided for this =
AC, using the Online Certificate =
Status
   Protocol (OCSP) defined in =
[OCSP]:
 
  &nbs=
p;   id-ad-ocsp OBJECT IDENTIFIER ::=3D { id-ad 1 =
}
 
   The =
accessLocation MUST contain a URI, and the URI MUST contain =
an
   HTTP URL [HTTP-URL] that specifies =
the location of an OCSP responder.
   The =
AC issuer MUST, of course, maintain an OCSP responder at =
this
   =
location.
 
  &n=
bsp;   =
name           =
id-ce-authorityInfoAccess
    &n=
bsp; =
OID            { =
id-pe 1 }
      =
syntax         =
AuthorityInfoAccessSyntax
    &n=
bsp; criticality    MUST be =
FALSE




_______________________=
________________________
pkix mailing =
list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix

 

------=_NextPart_000_0027_01CF5B12.099BAD10-- From nobody Fri Apr 18 06:23:07 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81F1A0158 for ; Fri, 18 Apr 2014 06:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S98Hx9UwfU9q for ; Fri, 18 Apr 2014 06:23:00 -0700 (PDT) Received: from epona03.ttu.edu (epona03.ttu.edu [129.118.201.76]) by ietfa.amsl.com (Postfix) with ESMTP id 22A941A0152 for ; Fri, 18 Apr 2014 06:23:00 -0700 (PDT) Received: from empusa01.ttu.edu (129.118.201.4) by mail.ttu.edu (129.118.201.76) with Microsoft SMTP Server id 14.3.174.1; Fri, 18 Apr 2014 08:22:55 -0500 Received: from CYCLOPS05.ttu.edu ([169.254.2.100]) by empusa01.ttu.edu ([129.118.201.4]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 08:22:55 -0500 From: "Sill, Alan" To: Erik Andersen Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwE2VPEAAACaOoAAAw+AgAAB8/AAATow5AAACpAdgAAPAKCAAAc6bYD//7xHsQ== Date: Fri, 18 Apr 2014 13:22:53 +0000 Message-ID: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw> <5350E92B.9000106@free.fr>,<002601cf5b01$4609b550$d21d1ff0$@x500.eu> In-Reply-To: <002601cf5b01$4609b550$d21d1ff0$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F1D29A9FC1D3493AACE7E2C868EA22F2ttuedu_" MIME-Version: 1.0 X-TechMail-Edge-Route: TTU Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/g_ebitz7bLc5yCTJ2X3AJh_Hfbc Cc: "pkix@ietf.org" Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:23:05 -0000 --_000_F1D29A9FC1D3493AACE7E2C868EA22F2ttuedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is also the case in compute-grid environments. In practice AC's are us= ed only for limited-lifetime proxies derived from a primary certificate. Th= e certificate itself is never used on its own and does not carry the role, = optional group or virtual-organization membership information needed to all= ow the certificate to be mapped to a local authorization by a relying party= . Such information is provided by the extended AC, but is present only in the= limited-lifetime proxy cert. OCSP is used (though not uniformly present fo= r all grid CAs, as CRLs are still widespread) and can be applied to revoke = a certificate but to my knowledge is not in use to revoke AC information. I= f a revocation were requested, it would be applied at the primary certifica= te level. Alan On Apr 18, 2014, at 7:26 AM, "Erik Andersen" > wrote: Whether ACs are of interest is an interesting question. In smart grid security, role-based access control (RBAC) seems for some rea= son as an important aspect. The lifetime of a role may be shorter than the = life of a public-key certificate. An AC is then seen as a temporary extensi= on to a public-key certificate. SAML is not considered here. Validation could be a major performance issue in a constrained environment. Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Friday, April 18, 2014 10:58 AM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Wen-Cheng, One one side your right: this would be the "normal" way to do it, in order = to allow to use an automatic and an interoperable mechanism. One the other side, there is also the possibility to have a "local configur= ation", but it is not an automatic nor an interoperable mechanism. So it is= unscalable. Using OCSP for ACs has not been fully thought, but only those using ACs wou= ld care. Who really cares ? Denis Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess ex= tension can be used to indicate OCSP is provided for that AC, OCSP is actua= lly can not be used for ACs beacuse it is not possible for the AA to issue = an public-key certificate to the OCSP Responder for delegating the revocati= on status response job. Wen-Cheng Wang ________________________________ From: pkix [pkix-bounces@ietf.org] on behalf = of David A. Cooper [david.cooper@nist.gov] Sent: Friday, April 18, 2014 4:46 AM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Here is text from RFC 5755 (which obsoleted RFC 3281) that is more unambigu= ous. The text in Section 4.3.4 of RFC 3281 is nearly identical. 4. Attribute Certificate Profile 4.3. Extensions 4.3.4. Authority Information Access The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by this profile since AC chains are not expected. The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the Online Certificate Status Protocol (OCSP) defined in [OCSP]: id-ad-ocsp OBJECT IDENTIFIER ::=3D { id-ad 1 } The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location. name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_F1D29A9FC1D3493AACE7E2C868EA22F2ttuedu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is also the case in compute-grid environments. In practice AC's a= re used only for limited-lifetime proxies derived from a primary certificat= e. The certificate itself is never used on its own and does not carry the r= ole, optional group or virtual-organization membership information needed to allow the certificate to be mapped to a l= ocal authorization by a relying party. 

Such information is provided by the extended AC, but is present only i= n the limited-lifetime proxy cert. OCSP is used (though not uniformly prese= nt for all grid CAs, as CRLs are still widespread) and can be applied to re= voke a certificate but to my knowledge is not in use to revoke AC information. If a revocation were requested, it= would be applied at the primary certificate level.

Alan



On Apr 18, 2014, at 7:26 AM, "Erik Andersen" <era@x500.eu> wrote:

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis
Sent: Friday, April 18, 2014 10:58 AM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

 

Wen-Cheng,

One one side your right: this would be the "normal" way to do it,= in order to allow to use an automatic and an interoperable mechanism.
 
One the other side, there is also the possibility to have a "local con= figuration", but it is not an automatic nor an interoperable mechanism= . So it is unscalable.

Using OCSP for ACs has not been fully thought, but only those using ACs wou= ld care. Who really cares ?

Denis

Although both RFC 3281 and RFC 5755 specify that the authorityInfoAccess=  extension can be used to indicate OCSP is provided for that AC, OCSP&= nbsp;is actually can not be used for ACs beacuse it is not possible fo= r the AA to issue an public-key certificate to the OCSP Responder for delegating the revocation status response job.

 = ;

Wen-Cheng Wang

 


From: pkix [pkix-bounces@ietf.org] on behalf of David A. Cooper [dav= id.cooper@nist.gov]
Sent: Friday, April 18, 2014 4:46 AM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

Here is text from RFC= 5755 (which obsoleted RFC 3281) that is more unambiguous. The text in Sect= ion 4.3.4 of RFC 3281 is nearly identical.

4.  Attribute Certificate Profile
 
4.3.  Extensions
 
4.3.4.  Authority Information Access
 
   The authorityInfoAccess extension, as defined in [PKIXPRO=
F], MAY be
   used to assist the AC verifier in checking the revocation=
 status of
   the AC.  Support for the id-ad-caIssuers accessMetho=
d is OPTIONAL by
   this profile since AC chains are not expected.=
 
   The following accessMethod is used to indicate that revoc=
ation status
   checking is provided for this AC, using the Online Certif=
icate Status
   Protocol (OCSP) defined in [OCSP]:
 
      id-ad-ocsp OBJECT IDENTIFIER ::=3D { id=
-ad 1 }
 
   The accessLocation MUST contain a URI, and the URI MUST c=
ontain an
   HTTP URL [HTTP-URL] that specifies the location of an OCS=
P responder.
   The AC issuer MUST, of course, maintain an OCSP responder=
 at this
   location.
 
      name      =
;     id-ce-authorityInfoAccess
      OID      =
      { id-pe 1 }
      syntax     &nb=
sp;   AuthorityInfoAccessSyntax
      criticality    MUST be F=
ALSE




_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.iet=
f.org/mailman/listinfo/pkix

 

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ie= tf.org/mailman/listinfo/pkix
--_000_F1D29A9FC1D3493AACE7E2C868EA22F2ttuedu_-- From nobody Fri Apr 18 08:56:53 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779571A039D for ; Wed, 16 Apr 2014 16:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAnR92Dh9yHQ; Wed, 16 Apr 2014 16:05:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 735771A0005; Wed, 16 Apr 2014 16:05:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: housley@vigilsec.com, draft-housley-pkix-oids@tools.ietf.org, pkix@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416230515.11768.25252.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 16:05:15 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/R8tnBXv09RPijX7Lu-k2VkaGVQw X-Mailman-Approved-At: Fri, 18 Apr 2014 08:56:50 -0700 Subject: [pkix] ID Tracker State Update Notice: X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 23:05:16 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-housley-pkix-oids/ From nobody Sat Apr 19 10:14:04 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03E1A0041 for ; Sat, 19 Apr 2014 10:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.063 X-Spam-Level: **** X-Spam-Status: No, score=4.063 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrQHkcbhGyBU for ; Sat, 19 Apr 2014 10:14:01 -0700 (PDT) Received: from scan1.cht.com.tw (scan1.cht.com.tw [202.39.168.17]) by ietfa.amsl.com (Postfix) with ESMTP id 418C91A0056 for ; Sat, 19 Apr 2014 10:14:00 -0700 (PDT) X-AuditID: 0aa00268-805cbba000003326-ef-5352af289fbb Received: from HUB4.app.corp.cht.com.tw (unknown [10.172.18.168]) by scan1.cht.com.tw (Symantec Mail Security) with ESMTP id 6F4B0154278 for ; Sun, 20 Apr 2014 01:15:20 +0800 (CST) Received: from MBS6.app.corp.cht.com.tw ([fe80::3178:69dd:b794:fa86]) by HUB4.app.corp.cht.com.tw ([fe80::f8db:4064:82dd:2fdb%12]) with mapi id 14.02.0342.003; Sun, 20 Apr 2014 01:13:55 +0800 From: =?big5?B?pP2k5aW/?= To: "pkix@ietf.org" Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwEbFzIAAACaOoAAAw+BgAAB8+8AATow5QAAGsSZCgAAj4Rj///x5YCAAiELZoAAeG1M Date: Sat, 19 Apr 2014 17:13:53 +0000 Message-ID: <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw>, <5350E92B.9000106@free.fr>, <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> In-Reply-To: <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.39.164.246] Content-Type: multipart/alternative; boundary="_000_20825998BCB8D84C983674C159E25E753D4C2C41mbs6appcorpchtc_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/VdruOJKmDk8yib68rzzD7UrIGSA Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 17:14:02 -0000 --_000_20825998BCB8D84C983674C159E25E753D4C2C41mbs6appcorpchtc_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 RGVuaXMsDQoNCk9mIGNvdXJzZSwgaWYgYSBsb2NhbCBjb25maWd1cmF0aW9uIGlzIGFkb3B0ZWQg dG8gYWNjZXB0IGEgbm9uLXN0YW5kYXJkIHdheSB0byBkbyBpdCwgYW55dGhpbmcgaXMgcG9zc2li bGUuDQoNCkhvd2V2ZXIsIHNpbmNlIGhlcmUgd2UgYXJlIGluIGEgV0cgY29uY2VybmluZyBJbnRl cm5ldCBTdGFuZGFyZCwgZm9sa3MgbWlnaHQgYmUgaW50ZXJlc3RlZCB0byBjbGFyaWZ5IHdoZXRo ZXIgY3VycmVudCBSRkNzIGRlZmluZWQgYnkgIHRoaXMgV0cgY2FuIHByb3ZpZGUgYSBzdGFuZGFy ZCB3YXkgdG8gY2hlY2sgQUMgcmV2b2NhdGlvbiBzdGF0dXMgb3ZlciBPQ1NQLg0KDQpNeSBjb25j bHVzaW9uIGlzIHRoYXQgdGhlIGN1cnJlbnQgQUMgYW5kIE9DU1AgUkZDcyBmYWlsZWQgdG8gcHJv dmlkZSBpdCBiZWNhdXNlIHRoZXJlIGFyZSBjb25mbGljdHMgYmV0d2VlbiBBQyBhbmQgT0NTUCBS RkNzLiBJIGJlbGlldmUgdGhhdCBhbiBleHRlbnNpb24gb3IgJ2JpcycgbmVlZHMgdG8gYmUgbWFk ZSBvdmVyIFJGQyA1NzU1IGluIG9yZGVyIHRvIHN1cHBvcnQgYSBzdGFuZGFyZCB3YXkgdG8gY2hl Y2sgQUMgcmV2b2NhdGlvbiBzdGF0dXMgb3ZlciBPQ1NQLCBidXQgSSBkbyBub3Qga25vdyB3aGV0 aGVyIHRoZXJlIGFyZSBhIHN1ZmZpY2llbnQgbnVtYmVyIG9mIGZvbGtzIGNhcmUgYWJvdXQgaXQg b3IgdGhpbmsgaXQgaXMgd29ydGggc3BlbmRpbmcgZWZmb3J0IHRvIGRlZmluZSBhbiBleHRlbnNp b24gb3IgbWFrZSBhICdiaXMnIHRvIFJGQyA1NzU1Pw0KDQpXZW4tQ2hlbmcgV2FuZw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcGtpeCBbcGtpeC1ib3VuY2VzQGll dGYub3JnXSBvbiBiZWhhbGYgb2YgRGVuaXMgW2RlbmlzLmlldGZAZnJlZS5mcl0NClNlbnQ6IEZy aWRheSwgQXByaWwgMTgsIDIwMTQgNDo1OCBQTQ0KVG86IHBraXhAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcGtpeF0gQUNzIGFuIE9DU1ANCg0KV2VuLUNoZW5nLA0KDQpPbmUgb25lIHNpZGUgeW91 ciByaWdodDogdGhpcyB3b3VsZCBiZSB0aGUgIm5vcm1hbCIgd2F5IHRvIGRvIGl0LCBpbiBvcmRl ciB0byBhbGxvdyB0byB1c2UgYW4gYXV0b21hdGljIGFuZCBhbiBpbnRlcm9wZXJhYmxlIG1lY2hh bmlzbS4NCg0KT25lIHRoZSBvdGhlciBzaWRlLCB0aGVyZSBpcyBhbHNvIHRoZSBwb3NzaWJpbGl0 eSB0byBoYXZlIGEgImxvY2FsIGNvbmZpZ3VyYXRpb24iLCBidXQgaXQgaXMgbm90IGFuIGF1dG9t YXRpYyBub3IgYW4gaW50ZXJvcGVyYWJsZSBtZWNoYW5pc20uIFNvIGl0IGlzIHVuc2NhbGFibGUu DQoNClVzaW5nIE9DU1AgZm9yIEFDcyBoYXMgbm90IGJlZW4gZnVsbHkgdGhvdWdodCwgYnV0IG9u bHkgdGhvc2UgdXNpbmcgQUNzIHdvdWxkIGNhcmUuIFdobyByZWFsbHkgY2FyZXMgPw0KDQpEZW5p cw0K --_000_20825998BCB8D84C983674C159E25E753D4C2C41mbs6appcorpchtc_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Denis,

Of course, if a local configuration is = adopted to accept a non-standard way to do it, anything is possible.=

However, since here we are in a WG conc= erning Internet Standard, folks might be interested to clarify whether curr= ent RFCs defined by  this WG can provide a standard way to check AC re= vocation status over OCSP.

My conclusion is that the current AC an= d OCSP RFCs failed to provide it because there are conflicts between AC and= OCSP RFCs. I believe that an extension or 'bis' needs to be made over RFC = 5755 in order to support a standard way to check AC revocation status over OCSP, but I do not know whether there are = a sufficient number of folks care about it or think it is worth spending ef= fort to define an extension or make a 'bis' to RFC 5755?

Wen-Cheng Wang


From: pkix [pkix-bounces@ietf.org] on behal= f of Denis [denis.ietf@free.fr]
Sent: Friday, April 18, 2014 4:58 PM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

Wen-Cheng,

One one side your right: this would be the "normal" way to do it,= in order to allow to use an automatic and an interoperable mechanism.
 
One the other side, there is also the possibility to have a "local con= figuration", but it is not an automatic nor an interoperable mechanism= . So it is unscalable.

Using OCSP for ACs has not been fully thought, but only those using ACs wou= ld care. Who really cares ?

Denis
--_000_20825998BCB8D84C983674C159E25E753D4C2C41mbs6appcorpchtc_-- From nobody Sat Apr 19 19:31:23 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137CD1A00D5 for ; Sat, 19 Apr 2014 19:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.262 X-Spam-Level: **** X-Spam-Status: No, score=4.262 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50du5kcKjwh6 for ; Sat, 19 Apr 2014 19:31:18 -0700 (PDT) Received: from scan2.cht.com.tw (scan3.cht.com.tw [202.39.168.43]) by ietfa.amsl.com (Postfix) with ESMTP id EE4DB1A0096 for ; Sat, 19 Apr 2014 19:31:17 -0700 (PDT) X-AuditID: 0aa00266-8a5ffba000000ba4-6e-5353323dd1dd Received: from CAS4.app.corp.cht.com.tw (unknown [10.172.18.166]) by scan2.cht.com.tw (Symantec Mail Security) with ESMTP id 9A7722BC001 for ; Sun, 20 Apr 2014 10:34:37 +0800 (CST) Received: from MBS6.app.corp.cht.com.tw ([fe80::3178:69dd:b794:fa86]) by CAS4.app.corp.cht.com.tw ([fe80::f179:c93d:e31a:eb23%12]) with mapi id 14.02.0342.003; Sun, 20 Apr 2014 10:31:12 +0800 From: =?iso-2022-jp?B?GyRCMiZKOEA1GyhC?= To: "pkix@ietf.org" Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwEbFzIAAACaOoAAAw+BgAAB8+8AATow5QAAGsSZCgAAj4Rj///x5YCAAiELZoAAeG1M//+JkoCAARjCQ////TDr Date: Sun, 20 Apr 2014 02:31:11 +0000 Message-ID: <20825998BCB8D84C983674C159E25E753D4C2F23@mbs6.app.corp.cht.com.tw> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw>, <5350E92B.9000106@free.fr>, <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw>, <000f01cf5bf5$e1017d00$a3047700$@x500.eu> In-Reply-To: <000f01cf5bf5$e1017d00$a3047700$@x500.eu> Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [202.39.164.246] Content-Type: multipart/alternative; boundary="_000_20825998BCB8D84C983674C159E25E753D4C2F23mbs6appcorpchtc_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/2o4mHR43wKbO9l_wGtY7sf6x9vg Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 02:31:22 -0000 --_000_20825998BCB8D84C983674C159E25E753D4C2F23mbs6appcorpchtc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Oops, I made a mistake. What I really meant is that an extension or 'bis' n= eeds to be made over RFC 6960 in order to support a standard way to check A= C revocation status over OCSP. My initial idea is as follows. Since an AA can not designate the OCSP responder by issuing a PKC, we need = to extend BasicOCSPResponse ASN.1 Syntax to allow it to designate the OCSP = responder by using an AC. BasicOCSPResponse ::=3D SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL attrCert [1] EXPLICIT AttributeCertificate OPTIONAL } -- This = field is to be used by an AA to designate the OCSP Responder. And then we need to specify the format of AC for an AA to designate the OCS= P responder. Wen-Cheng Wang =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: Erik Andersen [era@x500.eu] Sent: Sunday, April 20, 2014 1:36 AM To: =1B$B2&J8@5=1B(B Subject: RE: [pkix] ACs an OCSP Hi Wen-Cheng Wang, What aspects of RFC 5755 should be changed to be compatible with OCSP? Regards, Erik =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of ??? Sent: Saturday, April 19, 2014 7:14 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Denis, Of course, if a local configuration is adopted to accept a non-standard way= to do it, anything is possible. However, since here we are in a WG concerning Internet Standard, folks migh= t be interested to clarify whether current RFCs defined by this WG can pro= vide a standard way to check AC revocation status over OCSP. My conclusion is that the current AC and OCSP RFCs failed to provide it bec= ause there are conflicts between AC and OCSP RFCs. I believe that an extens= ion or 'bis' needs to be made over RFC 5755 in order to support a standard = way to check AC revocation status over OCSP, but I do not know whether ther= e are a sufficient number of folks care about it or think it is worth spend= ing effort to define an extension or make a 'bis' to RFC 5755? Wen-Cheng Wang =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: pkix [pkix-bounces@ietf.org] on behalf of Denis [denis.ietf@free.fr] Sent: Friday, April 18, 2014 4:58 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Wen-Cheng, One one side your right: this would be the "normal" way to do it, in order = to allow to use an automatic and an interoperable mechanism. One the other side, there is also the possibility to have a "local configur= ation", but it is not an automatic nor an interoperable mechanism. So it is= unscalable. Using OCSP for ACs has not been fully thought, but only those using ACs wou= ld care. Who really cares ? Denis --_000_20825998BCB8D84C983674C159E25E753D4C2F23mbs6appcorpchtc_ Content-Type: text/html; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: quoted-printable

Oops, I made a mistake. What I really meant is that an extension or 'bis= ' needs to be made over RFC 6960 in order to support a standard way to chec= k AC revocation status over OCSP.

My initial idea is as follows.

Since an AA can not designate the OCSP responder by issuing a PKC, we need = to extend BasicOCSPResponse ASN.1 Syntax to allow it to designate the OCSP = responder by using an AC.

   BasicOCSPResponse       ::=3D SE= QUENCE {
      tbsResponseData     = ; ResponseData,
      signatureAlgorithm   AlgorithmIden= tifier,
      signature      = ;      BIT STRING,
      certs      &nb= sp;     [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL       attrCert      =   [1] EXPLICIT AttributeCertificate OPTIONAL } -- This field is t= o be used by an AA to designate the OCSP Responder.

And then we need to specify the format of AC for an AA to designate th= e OCSP responder.

Wen-Cheng Wang


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: Erik Andersen [era@x500.eu]
Sent: Sunday, April 20, 2014 1:36 AM
To: =1B$B2&J8@5=1B(B
Subject: RE: [pkix] ACs an OCSP


Hi Wen-Cheng Wang,
 
What aspects of RFC 5755 should be changed to be compatible with OCSP?
 
Regards,
 
Erik

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 
 
From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of ???
Sent: Saturday, April 19, 2014 7:14 PM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP
 
Denis,
 
Of course, if a local configuration is adopted to accept a non-standard way= to do it, anything is possible.
 
However, since here we are in a WG concerning Internet Standard, folks migh= t be interested to clarify whether current RFCs defined by  this WG ca= n provide a standard way to check AC revocation status over OCSP.
 
My conclusion is that the current AC and OCSP RFCs failed to provide it bec= ause there are conflicts between AC and OCSP RFCs. I believe that an extens= ion or 'bis' needs to be made over RFC 5755 in order to support a standard = way to check AC revocation status over OCSP, but I do not know whether there are a sufficient number of folk= s care about it or think it is worth spending effort to define an extension= or make a 'bis' to RFC 5755?
 
Wen-Cheng Wang
 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: pkix [pkix-bounces@ietf.org] on behalf of Denis [denis.ietf@free.fr]<= br> Sent: Friday, April 18, 2014 4:58 PM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP
Wen-Cheng,

One one side your right: this would be the "normal" way to do it,= in order to allow to use an automatic and an interoperable mechanism.
 
One the other side, there is also the possibility to have a "local con= figuration", but it is not an automatic nor an interoperable mechanism= . So it is unscalable.

Using OCSP for ACs has not been fully thought, but only those using ACs wou= ld care. Who really cares ?

Denis

--_000_20825998BCB8D84C983674C159E25E753D4C2F23mbs6appcorpchtc_-- From nobody Mon Apr 21 08:31:30 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D711A01FF for ; Mon, 21 Apr 2014 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv0y7-7RcHub for ; Mon, 21 Apr 2014 08:31:24 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id C36F31A01FA for ; Mon, 21 Apr 2014 08:31:23 -0700 (PDT) Received: from ([62.44.134.128]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id HTA01214 for ; Mon, 21 Apr 2014 17:31:14 +0200 From: "Erik Andersen" To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw>, <5350E92B.9000106@free.fr>, <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw>, <000f01cf5bf5$e1017d00$a3047700$@x500.eu> <20825998BCB8D84C983674C159E25E753D4C2F23@mbs6.app.corp.cht.com.tw> In-Reply-To: <20825998BCB8D84C983674C159E25E753D4C2F23@mbs6.app.corp.cht.com.tw> Date: Mon, 21 Apr 2014 17:31:09 +0200 Message-ID: <000701cf5d76$bb1f79c0$315e6d40$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01CF5D87.7EAF0080" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG/+lgCTTm0O0fUfLlk3oIfj32E1gFYE2fpAZPvIRgCVTe9lwKsMGH1Aileu/8DNtyldgLhHw9UAIk5up8BAe+h6gKSeHgmAjOHeuKahvh9AA== Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/J9LvM9L6OKZw4cRfcNHUM8IIqNY Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:31:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01CF5D87.7EAF0080 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Thanks Wen-Cheng Wang. A related question: Can the Authority Information Access extension be included in an attribute certificate? Erik From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of ??? Sent: Sunday, April 20, 2014 4:31 AM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Oops, I made a mistake. What I really meant is that an extension or 'bis' needs to be made over RFC 6960 in order to support a standard way to check AC revocation status over OCSP. My initial idea is as follows. Since an AA can not designate the OCSP responder by issuing a PKC, we need to extend BasicOCSPResponse ASN.1 Syntax to allow it to designate the OCSP responder by using an AC. BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL attrCert [1] EXPLICIT AttributeCertificate OPTIONAL } -- This field is to be used by an AA to designate the OCSP Responder. And then we need to specify the format of AC for an AA to designate the OCSP responder. Wen-Cheng Wang ====================================== From: Erik Andersen [era@x500.eu] Sent: Sunday, April 20, 2014 1:36 AM To: $B2&J8@5(B Subject: RE: [pkix] ACs an OCSP Hi Wen-Cheng Wang, What aspects of RFC 5755 should be changed to be compatible with OCSP? Regards, Erik ====================================== From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of ??? Sent: Saturday, April 19, 2014 7:14 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Denis, Of course, if a local configuration is adopted to accept a non-standard way to do it, anything is possible. However, since here we are in a WG concerning Internet Standard, folks might be interested to clarify whether current RFCs defined by this WG can provide a standard way to check AC revocation status over OCSP. My conclusion is that the current AC and OCSP RFCs failed to provide it because there are conflicts between AC and OCSP RFCs. I believe that an extension or 'bis' needs to be made over RFC 5755 in order to support a standard way to check AC revocation status over OCSP, but I do not know whether there are a sufficient number of folks care about it or think it is worth spending effort to define an extension or make a 'bis' to RFC 5755? Wen-Cheng Wang ====================================== From: pkix [pkix-bounces@ietf.org] on behalf of Denis [denis.ietf@free.fr] Sent: Friday, April 18, 2014 4:58 PM To: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP Wen-Cheng, One one side your right: this would be the "normal" way to do it, in order to allow to use an automatic and an interoperable mechanism. One the other side, there is also the possibility to have a "local configuration", but it is not an automatic nor an interoperable mechanism. So it is unscalable. Using OCSP for ACs has not been fully thought, but only those using ACs would care. Who really cares ? Denis ------=_NextPart_000_0008_01CF5D87.7EAF0080 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Thanks Wen-Cheng = Wang.

 

A related question: Can the Authority = Information Access extension be included in an attribute = certificate?

 

Erik

 

From: pkix = [mailto:pkix-bounces@ietf.org] On Behalf Of ???
Sent: = Sunday, April 20, 2014 4:31 AM
To: = pkix@ietf.org
Subject: Re: [pkix] ACs an = OCSP

 

Oops, I made a = mistake. What I really meant is that an extension or 'bis' needs to be = made over RFC 6960 in order to support a standard way to check AC = revocation status over OCSP.

My initial idea is as = follows.

Since an AA can not designate the OCSP responder by = issuing a PKC, we need to extend BasicOCSPResponse ASN.1 Syntax to allow = it to designate the OCSP responder by using an AC.

   = BasicOCSPResponse       ::=3D SEQUENCE = {
      = tbsResponseData      = ResponseData,
      = signatureAlgorithm   = AlgorithmIdentifier,
      = signature          &nbs= p; BIT STRING,
      = certs            = [0] EXPLICIT SEQUENCE OF Certificate = OPTIONAL
      = attrCert        [1] EXPLICIT = AttributeCertificate OPTIONAL } -- This field is to be used by an AA to = designate the OCSP Responder.

And then we need to specify the = format of AC for an AA to designate the OCSP = responder.

Wen-Cheng = Wang


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: = Erik Andersen [era@x500.eu]
Sent: Sunday, April 20, 2014 1:36 = AM
To: =1B$B2&J8@5=1B(B
Subject: RE: [pkix] = ACs an OCSP


Hi Wen-Cheng Wang,
 
What aspects of = RFC 5755 should be changed to be compatible with = OCSP?
 
Regards,
 
Erik

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 
 
From: pkix [mailto:pkix-bounces@ietf.org] = On Behalf Of ???
Sent: Saturday, April 19, 2014 7:14 PM
To: pkix@ietf.org
Subject: Re: [pkix] = ACs an OCSP
 
Denis,
 
Of course, if a local = configuration is adopted to accept a non-standard way to do it, anything = is possible.
 
However, since here we are in a WG concerning = Internet Standard, folks might be interested to clarify whether current = RFCs defined by  this WG can provide a standard way to check AC = revocation status over OCSP.
 
My conclusion is that the = current AC and OCSP RFCs failed to provide it because there are = conflicts between AC and OCSP RFCs. I believe that an extension or 'bis' = needs to be made over RFC 5755 in order to support a standard way to = check AC revocation status over OCSP, but I do not know whether there = are a sufficient number of folks care about it or think it is worth = spending effort to define an extension or make a 'bis' to RFC = 5755?
 
Wen-Cheng = Wang
 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Fr= om: pkix [pkix-bounces@ietf.org] on behalf of Denis = [denis.ietf@free.fr]
Sent: Friday, April 18, 2014 4:58 PM
To: pkix@ietf.org
Subject: Re: [pkix] = ACs an OCSP
Wen-Cheng,

One one side your right: this would be = the "normal" way to do it, in order to allow to use an = automatic and an interoperable mechanism.
 
One the other = side, there is also the possibility to have a "local = configuration", but it is not an automatic nor an interoperable = mechanism. So it is unscalable.

Using OCSP for ACs has not been = fully thought, but only those using ACs would care. Who really cares = ?

Denis

------=_NextPart_000_0008_01CF5D87.7EAF0080-- From nobody Mon Apr 21 09:02:24 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF551A0232 for ; Mon, 21 Apr 2014 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EusZe4H-6gKR for ; Mon, 21 Apr 2014 09:02:11 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3525A1A0231 for ; Mon, 21 Apr 2014 09:01:52 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 84B7AF2C07E; Mon, 21 Apr 2014 12:01:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 1BH03QDbxT+5; Mon, 21 Apr 2014 12:01:15 -0400 (EDT) Received: from [172.17.153.14] (unknown [179.189.232.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7E793F3C004; Mon, 21 Apr 2014 12:01:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-11-1029557266 From: Russ Housley In-Reply-To: <000701cf5d76$bb1f79c0$315e6d40$@x500.eu> Date: Mon, 21 Apr 2014 12:01:08 -0400 Message-Id: <13F8928E-1BED-49DF-B087-7BF91E03F208@vigilsec.com> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw>, <5350E92B.9000106@free.fr>, <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw>, <000f01cf5bf5$e1017d00$a3047700$@x500.eu> <20825998BCB8D84C983674C159E25E753D4C2F23@mbs6.app.corp.cht.com.tw> <000701cf5d76$bb1f79c0$315e6d40$@x500.eu> To: Erik Andersen X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/BGjKENBgYWCqrTimPzYQkz32-sA Cc: pkix@ietf.org Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:02:19 -0000 --Apple-Mail-11-1029557266 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RFC 3281 contains the answer... 4.3.4 Authority Information Access The authorityInformationAccess extension, as defined in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. Support for the id-ad-caIssuers accessMethod is NOT REQUIRED by this profile since AC chains are not expected. The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the OCSP protocol defined in [OCSP]: id-ad-ocsp OBJECT IDENTIFIER ::=3D { id-ad 1 } The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location. name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE On Apr 21, 2014, at 11:31 AM, Erik Andersen wrote: > Thanks Wen-Cheng Wang. > =20 > A related question: Can the Authority Information Access extension be = included in an attribute certificate? > =20 > Erik --Apple-Mail-11-1029557266 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii RFC = 3281 contains the answer...

4.3.4   = Authority Information Access

   The = authorityInformationAccess extension, as defined in = [PKIXPROF],
   MAY be used to assist the AC verifier = in checking the revocation
   status of the AC. =  Support for the id-ad-caIssuers accessMethod is
  =  NOT REQUIRED by this profile since AC chains are not = expected.

   The following = accessMethod is used to indicate that revocation status
  =  checking is provided for this AC, using the OCSP protocol defined = in
   [OCSP]:

    =   id-ad-ocsp OBJECT IDENTIFIER ::=3D { id-ad 1 = }

   The accessLocation MUST contain = a URI, and the URI MUST contain an
   HTTP URL [URL] = that specifies the location of an OCSP responder. =  The
   AC issuer MUST, of course, maintain an = OCSP responder at this
  =  location.

      name =           = id-ce-authorityInfoAccess
      OID   =          { id-pe 1 }
    =   syntax         = AuthorityInfoAccessSyntax
      criticality =    MUST be = FALSE



On Apr = 21, 2014, at 11:31 AM, Erik Andersen wrote:

Thanks Wen-Cheng = Wang.
A related = question: Can the Authority Information Access extension be included in = an attribute certificate?
Thread-Topic: [pkix] ACs an OCSP Thread-Index: Ac9Qz2++GSAPSCCkRAaVwjME5VKUOwEbFzIAAACaOoAAAw+BgAAB8+8AATow5QAAGsSZCgAAj4Rj///x5YCAAiELZoAAeG1M//+JkoCAARjCQ////TDrgAHrxICAAI294g== Date: Mon, 21 Apr 2014 16:06:07 +0000 Message-ID: <20825998BCB8D84C983674C159E25E753D4C3BBC@mbs6.app.corp.cht.com.tw> References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw>, <5350E92B.9000106@free.fr>, <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw>, <000f01cf5bf5$e1017d00$a3047700$@x500.eu> <20825998BCB8D84C983674C159E25E753D4C2F23@mbs6.app.corp.cht.com.tw>, <000701cf5d76$bb1f79c0$315e6d40$@x500.eu> In-Reply-To: <000701cf5d76$bb1f79c0$315e6d40$@x500.eu> Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.39.164.246] Content-Type: multipart/alternative; boundary="_000_20825998BCB8D84C983674C159E25E753D4C3BBCmbs6appcorpchtc_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/gK_iHAPsrx-DrFQE2Zdeg_Bn6As Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:06:17 -0000 --_000_20825998BCB8D84C983674C159E25E753D4C3BBCmbs6appcorpchtc_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 RXJpYywNCg0KWWVzLCBib3RoIFJGQyA1NzU1IGFuZCBSRkMgMzI4MSBleHBsaWNpdGx5IGFsbG93 IHRvIGluY2x1ZGUgdGhlIEF1dGhvcml0eSBJbmZvcm1hdGlvbiBBY2Nlc3MgZXh0ZW5zaW9uIGlu IGFuIEFDLiBQbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiA0LjMuNCBvZiBSRkMgNTc1NSBvciBSRkMg MzI4MS4NCg0KV2VuLUNoZW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBwa2l4IFtwa2l4LWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZiBFcmlrIEFuZGVy c2VuIFtlcmFAeDUwMC5ldV0NClNlbnQ6IE1vbmRheSwgQXByaWwgMjEsIDIwMTQgMTE6MzEgUE0N ClRvOiBwa2l4QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BraXhdIEFDcyBhbiBPQ1NQDQoNClRo YW5rcyBXZW4tQ2hlbmcgV2FuZy4NCg0KQSByZWxhdGVkIHF1ZXN0aW9uOiBDYW4gdGhlIEF1dGhv cml0eSBJbmZvcm1hdGlvbiBBY2Nlc3MgZXh0ZW5zaW9uIGJlIGluY2x1ZGVkIGluIGFuIGF0dHJp YnV0ZSBjZXJ0aWZpY2F0ZT8NCg0KRXJpaw0KDQpGcm9tOiBwa2l4IFttYWlsdG86cGtpeC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgPz8/DQpTZW50OiBTdW5kYXksIEFwcmlsIDIwLCAy MDE0IDQ6MzEgQU0NClRvOiBwa2l4QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BraXhdIEFDcyBh biBPQ1NQDQoNCg0KT29wcywgSSBtYWRlIGEgbWlzdGFrZS4gV2hhdCBJIHJlYWxseSBtZWFudCBp cyB0aGF0IGFuIGV4dGVuc2lvbiBvciAnYmlzJyBuZWVkcyB0byBiZSBtYWRlIG92ZXIgUkZDIDY5 NjAgaW4gb3JkZXIgdG8gc3VwcG9ydCBhIHN0YW5kYXJkIHdheSB0byBjaGVjayBBQyByZXZvY2F0 aW9uIHN0YXR1cyBvdmVyIE9DU1AuDQoNCk15IGluaXRpYWwgaWRlYSBpcyBhcyBmb2xsb3dzLg0K DQpTaW5jZSBhbiBBQSBjYW4gbm90IGRlc2lnbmF0ZSB0aGUgT0NTUCByZXNwb25kZXIgYnkgaXNz dWluZyBhIFBLQywgd2UgbmVlZCB0byBleHRlbmQgQmFzaWNPQ1NQUmVzcG9uc2UgQVNOLjEgU3lu dGF4IHRvIGFsbG93IGl0IHRvIGRlc2lnbmF0ZSB0aGUgT0NTUCByZXNwb25kZXIgYnkgdXNpbmcg YW4gQUMuDQoNCiAgIEJhc2ljT0NTUFJlc3BvbnNlICAgICAgIDo6PSBTRVFVRU5DRSB7DQogICAg ICB0YnNSZXNwb25zZURhdGEgICAgICBSZXNwb25zZURhdGEsDQogICAgICBzaWduYXR1cmVBbGdv cml0aG0gICBBbGdvcml0aG1JZGVudGlmaWVyLA0KICAgICAgc2lnbmF0dXJlICAgICAgICAgICAg QklUIFNUUklORywNCiAgICAgIGNlcnRzICAgICAgICAgICAgWzBdIEVYUExJQ0lUIFNFUVVFTkNF IE9GIENlcnRpZmljYXRlIE9QVElPTkFMDQogICAgICBhdHRyQ2VydCAgICAgICAgWzFdIEVYUExJ Q0lUIEF0dHJpYnV0ZUNlcnRpZmljYXRlIE9QVElPTkFMIH0gLS0gVGhpcyBmaWVsZCBpcyB0byBi ZSB1c2VkIGJ5IGFuIEFBIHRvIGRlc2lnbmF0ZSB0aGUgT0NTUCBSZXNwb25kZXIuDQoNCkFuZCB0 aGVuIHdlIG5lZWQgdG8gc3BlY2lmeSB0aGUgZm9ybWF0IG9mIEFDIGZvciBhbiBBQSB0byBkZXNp Z25hdGUgdGhlIE9DU1AgcmVzcG9uZGVyLg0KDQpXZW4tQ2hlbmcgV2FuZw0K --_000_20825998BCB8D84C983674C159E25E753D4C3BBCmbs6appcorpchtc_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Eric,

Yes, both RFC 5755 and RFC 3281 explicitly allow to i= nclude the Authority Information Access extension in an AC. Please refer to= section 4.3.4 of RFC 5755 o= r RFC 3281.

Wen-Cheng


From: pkix [pkix-= bounces@ietf.org] on behalf of Erik Andersen [era@x500.eu]
Sent: Monday, April 21, 2014 11:31 PM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

Thanks Wen-Cheng Wang.<= /span>

 

A related question: Can= the Authority Information Access extension be included in an attribute cer= tificate?

 

Erik

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of ???
Sent: Sunday, April 20, 2014 4:31 AM
To: pkix@ietf.org
Subject: Re: [pkix] ACs an OCSP

 

Oops, I made a mistake. What I really meant is that an extension or= 'bis' needs to be made over RFC 6960 in order to support a standard way to= check AC revocation status over OCSP.

My initial idea is as follows.

Since an AA can not designate the OCSP responder by issuing a PKC, we need = to extend BasicOCSPResponse ASN.1 Syntax to allow it to designate the OCSP = responder by using an AC.

   BasicOCSPResponse       ::=3D SE= QUENCE {
      tbsResponseData     = ; ResponseData,
      signatureAlgorithm   AlgorithmIden= tifier,
      signature      = ;      BIT STRING,
      certs      &nb= sp;     [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL       attrCert      =   [1] EXPLICIT AttributeCertificate OPTIONAL } -- This field is t= o be used by an AA to designate the OCSP Responder.

And then we need to specify the format of AC for an AA to designate th= e OCSP responder.

Wen-Cheng Wang

--_000_20825998BCB8D84C983674C159E25E753D4C3BBCmbs6appcorpchtc_-- From nobody Mon Apr 21 17:59:05 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2D1A0332 for ; Mon, 21 Apr 2014 17:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_qpiugLxO-k for ; Mon, 21 Apr 2014 17:59:02 -0700 (PDT) Received: from p02c11o142.mxlogic.net (p02c11o142.mxlogic.net [208.65.144.75]) by ietfa.amsl.com (Postfix) with ESMTP id 395B01A0329 for ; Mon, 21 Apr 2014 17:59:02 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB025.mail.lan) by p02c11o142.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id 0deb5535.0.30374.00-375.70871.p02c11o142.mxlogic.net (envelope-from ); Mon, 21 Apr 2014 18:58:57 -0600 (MDT) X-MXL-Hash: 5355bed1641df082-2f1d955d12e6fcfaa8cd1d84465d26891bc652de Received: from MAILR001.mail.lan ([10.110.18.28]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 21 Apr 2014 20:58:56 -0400 From: Jacob Dilles To: "pkix@ietf.org" Date: Mon, 21 Apr 2014 20:58:55 -0400 Thread-Topic: RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes Thread-Index: Ac9dxg8+C0cfAtlBT3uHp9h4p6VW6g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=VJ1Tnr/X c=1 sm=1 tr=0 a=PkGQAut8NMstkBiKWxohFA==] X-AnalysisOut: [:17 a=VoY0yXNOFCIA:10 a=y-apFrgtaY8A:10 a=aRBQtKuRrKEA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=MwhnZbRVAAAA:8 a=YlV] X-AnalysisOut: [TAMxIAAAA:8 a=85Q1HAgS79UXiLQf8xsA:9 a=PNgLbpU-bo8n4dH_:21] X-AnalysisOut: [ a=DwLmMN7jdkIK_sxe:21 a=wPNLvfGTeEIA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014042135); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.25.75.234] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/nbz-esqb4WKv7Ow0jwJRc8LsS3M Subject: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 00:59:04 -0000 We are doing in-depth conformance validation of RFC3369/5652 CMS objects with SignedData (Section 5) content type. One of the things we check is sort-order on Set-Of types, as in | SignedAttributes ::=3D SET SIZE (1..MAX) OF Attribute =20 which must be DER encoded per Section 2 pg. 3 of the RFC. As specified by the reference [DER], X.509-88 sec 8.7 (p14): | e) the components of a Set-of type shall be encoded in ascending | order of their octet value; Per the terminology of X.209 BER, this is unambiguous in excluding length from the comparison (not 'tag' nor 'length', only 'value'); however the point was clarified later in X.690-0207 (p19): | 11.6 The encodings of the component values of a set-of value shall | appear in ascending order, the encodings being compared as | octet strings with the shorter components being padded at their | trailing end with 0-octets. | =20 | NOTE =AD The padding octets are for comparison purposes only | and do not appear in the encodings. Which is similar (component 'values' .. 'ascending order'), but goes on to specifically require that length be excluded from comparison (otherwise, a trailing-zero padding scheme is unnecessary, lexicographical sorting of the definite-length encoding of types with the same tag will always result in shortest-length-first order). We have noticed a discrepancy between this specification and many CMS objects, both found in the wild and produced in testing several popular cryptographic libraries. Three common SignedAttributes are ContentType (11.1), MessageDigest (11.2), and SigningTime (11.3); IDENTIFIED BY 1.2.840.113549.1.9.3, .4, and .5 respectively (from PKCS9). Per [DER], given the following input: a. ContentType: 2.23.136.1.1.1 b. MessageDigest: d21c11ee67e200fd452b587cc3bc5cb4b0ab7a92c16389fce96c7a79aa714ebc c. SigningTime: 070131203016Z We should encode the Set-of Attributes ordered by their encoded value, which first differs at the 11th octet: 1. ContentType (<30 15> 06092A864886F70d0109[03]..) =20 2. MessageDigest (<30 2F> 06092A864886F70d0109[04]..) =20 3. SigningTime (<30 1C> 06092A864886F70d0109[05]..) But we find that as encoded, they are ordered as: 1. ContentType (<30 [15]> ..) =20 2. SigningTime (<30 [1C]> ..) =20 3. MessageDigest (<30 [2F]> ..) i.e. sorting the Set-of component types by their DER encoding, including tag and length (15 < 28 < 47). Despite being in violation of the specification(s), this is simpler from an implementation perspective and seems to have become a de facto standard. My question is: For the purpose of determining if an object conforms to the RFC3852 and/or RFC5652 CMS profile, should we consider the second SignedAttributes Set-of encoding method compliant? Thanks, Jacob Dilles From nobody Mon Apr 21 19:19:36 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994CC1A0075 for ; Mon, 21 Apr 2014 19:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeUeQBWrvlHv for ; Mon, 21 Apr 2014 19:19:32 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id B99D01A0114 for ; Mon, 21 Apr 2014 19:19:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,900,1389704400"; d="scan'208";a="195509461" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 22 Apr 2014 12:19:24 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7415"; a="214514745" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipccvi.tcif.telstra.com.au with ESMTP; 22 Apr 2014 12:19:24 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 22 Apr 2014 12:19:23 +1000 From: "Manger, James" To: Jacob Dilles , "pkix@ietf.org" Date: Tue, 22 Apr 2014 12:19:21 +1000 Thread-Topic: RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes Thread-Index: Ac9dxg8+C0cfAtlBT3uHp9h4p6VW6gAB8qwQ Message-ID: <255B9BB34FB7D647A506DC292726F6E115452B12CD@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/3nS8V08uRLALtejQMuuSCJs3Zik Subject: Re: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 02:19:34 -0000 SmFjb2IsDQoNClRoZSB0YWcgJiBsZW5ndGggYXJlIG5vdCBleGNsdWRlZCB3aGVuIHNvcnRpbmcg YSBTRVQgT0YgZWxlbWVudHMuIFlvdSBhcmUgbWlzcmVhZGluZyB0aGUgc3BlY3MuDQoNClRoZSAx OTg4IHRleHQgbWlnaHQgaGF2ZSBiZWVuIGEgYml0IHVuY2xlYXIgYnkgc2F5aW5nICJ0aGUgY29t cG9uZW50cyAuLiBvY3RldCB2YWx1ZSIuIFRoZSAyMDAyIHRleHQgaXMgY3J5c3RhbCBjbGVhcjog ImVuY29kaW5ncyIgYXJlIGNvbXBhcmVkLiBBbiBlbmNvZGluZyBpbmNsdWRlcyB0YWctbGVuZ3Ro LXZhbHVlLiBJdCBtYWtlcyBubyBzZW5zZSB0byBleGNsdWRlIHRhZyAmIGxlbmd0aCBhcyB0aGVu IHNvcnRpbmcgd291bGQgbm90IGJlIHVuaXF1ZSB3aGVuIHRoZSB2YWx1ZXMgb2YgdHdvIGNvbXBv bmVudHMgd2VyZSBlbXB0eSAob3IgaWRlbnRpY2FsKS4gVGhlIHRhbGsgb2YgcGFkZGluZyBqdXN0 IG1ha2VzIHN1cmUgdGhhdCB3aGVuIGNvbXBhcmluZyBlbmNvZGluZ3Mgb2YgZGlmZmVyZW50IGxl bmd0aHMgdGhlaXIgZmlyc3QgYnl0ZXMgYXJlIGFsaWduZWQsIG5vdCB0aGVpciBsYXN0IGJ5dGVz Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBwa2l4IFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFjb2Ig RGlsbGVzDQpTZW50OiBUdWVzZGF5LCAyMiBBcHJpbCAyMDE0IDEwOjU5IEFNDQpUbzogcGtpeEBp ZXRmLm9yZw0KU3ViamVjdDogW3BraXhdIFJGQzM4NTIvUkZDNTY1MiBDTVMgREVSIFNldC1vZiBl bmNvZGluZyBpbiBTaWduZWRBdHRyaWJ1dGVzDQoNCldlIGFyZSBkb2luZyBpbi1kZXB0aCBjb25m b3JtYW5jZSB2YWxpZGF0aW9uIG9mIFJGQzMzNjkvNTY1MiBDTVMgb2JqZWN0cw0Kd2l0aCBTaWdu ZWREYXRhIChTZWN0aW9uIDUpIGNvbnRlbnQgdHlwZS4NCg0KDQpPbmUgb2YgdGhlIHRoaW5ncyB3 ZSBjaGVjayBpcyBzb3J0LW9yZGVyIG9uIFNldC1PZiB0eXBlcywgYXMgaW4NCg0KDQp8ICAgIFNp Z25lZEF0dHJpYnV0ZXMgOjo9IFNFVCBTSVpFICgxLi5NQVgpIE9GIEF0dHJpYnV0ZQ0KDQoNCiAg ICANCndoaWNoIG11c3QgYmUgREVSIGVuY29kZWQgcGVyIFNlY3Rpb24gMiBwZy4gMyBvZiB0aGUg UkZDLiBBcyBzcGVjaWZpZWQNCmJ5IHRoZSByZWZlcmVuY2UgW0RFUl0sIFguNTA5LTg4IHNlYyA4 LjcgKHAxNCk6DQoNCg0KfCAgIGUpIHRoZSBjb21wb25lbnRzIG9mIGEgU2V0LW9mIHR5cGUgc2hh bGwgYmUgZW5jb2RlZCBpbiBhc2NlbmRpbmcNCnwgICAgICBvcmRlciBvZiB0aGVpciBvY3RldCB2 YWx1ZTsNCg0KDQpQZXIgdGhlIHRlcm1pbm9sb2d5IG9mIFguMjA5IEJFUiwgdGhpcyBpcyB1bmFt YmlndW91cyBpbiBleGNsdWRpbmcNCmxlbmd0aCBmcm9tIHRoZSBjb21wYXJpc29uIChub3QgJ3Rh Zycgbm9yICdsZW5ndGgnLCBvbmx5ICd2YWx1ZScpOw0KaG93ZXZlciB0aGUgcG9pbnQgd2FzIGNs YXJpZmllZCBsYXRlciBpbiBYLjY5MC0wMjA3IChwMTkpOg0KDQoNCnwgICAxMS42IFRoZSBlbmNv ZGluZ3Mgb2YgdGhlIGNvbXBvbmVudCB2YWx1ZXMgb2YgYSBzZXQtb2YgdmFsdWUgc2hhbGwNCnwg ICAgICAgIGFwcGVhciBpbiBhc2NlbmRpbmcgb3JkZXIsIHRoZSBlbmNvZGluZ3MgYmVpbmcgY29t cGFyZWQgYXMNCnwgICAgICAgIG9jdGV0IHN0cmluZ3Mgd2l0aCB0aGUgc2hvcnRlciBjb21wb25l bnRzIGJlaW5nIHBhZGRlZCBhdCB0aGVpcg0KfCAgICAgICAgdHJhaWxpbmcgZW5kIHdpdGggMC1v Y3RldHMuDQp8DQogICAgDQp8ICAgICAgICBOT1RFIMKtIFRoZSBwYWRkaW5nIG9jdGV0cyBhcmUg Zm9yIGNvbXBhcmlzb24gcHVycG9zZXMgb25seQ0KfCAgICAgICAgYW5kIGRvIG5vdCBhcHBlYXIg aW4gdGhlIGVuY29kaW5ncy4NCg0KDQpXaGljaCBpcyBzaW1pbGFyIChjb21wb25lbnQgJ3ZhbHVl cycgLi4gJ2FzY2VuZGluZyBvcmRlcicpLCBidXQgZ29lcyBvbg0KdG8gc3BlY2lmaWNhbGx5IHJl cXVpcmUgdGhhdCBsZW5ndGggYmUgZXhjbHVkZWQgZnJvbSBjb21wYXJpc29uDQoob3RoZXJ3aXNl LCBhIHRyYWlsaW5nLXplcm8gcGFkZGluZyBzY2hlbWUgaXMgdW5uZWNlc3NhcnksDQpsZXhpY29n cmFwaGljYWwgc29ydGluZyBvZiB0aGUgZGVmaW5pdGUtbGVuZ3RoIGVuY29kaW5nIG9mIHR5cGVz DQp3aXRoIHRoZSBzYW1lIHRhZyB3aWxsIGFsd2F5cyByZXN1bHQgaW4gc2hvcnRlc3QtbGVuZ3Ro LWZpcnN0IG9yZGVyKS4NCg0KDQpXZSBoYXZlIG5vdGljZWQgYSBkaXNjcmVwYW5jeSBiZXR3ZWVu IHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgbWFueSBDTVMNCm9iamVjdHMsIGJvdGggZm91bmQgaW4g dGhlIHdpbGQgYW5kIHByb2R1Y2VkIGluIHRlc3Rpbmcgc2V2ZXJhbCBwb3B1bGFyDQpjcnlwdG9n cmFwaGljIGxpYnJhcmllcy4NCg0KDQpUaHJlZSBjb21tb24gU2lnbmVkQXR0cmlidXRlcyBhcmUg Q29udGVudFR5cGUgKDExLjEpLCBNZXNzYWdlRGlnZXN0DQooMTEuMiksIGFuZCBTaWduaW5nVGlt ZSAoMTEuMyk7IElERU5USUZJRUQgQlkgMS4yLjg0MC4xMTM1NDkuMS45LjMsIC40LA0KYW5kIC41 IHJlc3BlY3RpdmVseSAoZnJvbSBQS0NTOSkuIFBlciBbREVSXSwgZ2l2ZW4gdGhlDQpmb2xsb3dp bmcgaW5wdXQ6DQoNCg0KICAgIGEuIENvbnRlbnRUeXBlOiAgIDIuMjMuMTM2LjEuMS4xDQoNCiAg ICBiLiBNZXNzYWdlRGlnZXN0Og0KZDIxYzExZWU2N2UyMDBmZDQ1MmI1ODdjYzNiYzVjYjRiMGFi N2E5MmMxNjM4OWZjZTk2YzdhNzlhYTcxNGViYw0KDQogICAgYy4gU2lnbmluZ1RpbWU6ICAgMDcw MTMxMjAzMDE2Wg0KDQoNCldlIHNob3VsZCBlbmNvZGUgdGhlIFNldC1vZiBBdHRyaWJ1dGVzIG9y ZGVyZWQgYnkgdGhlaXIgZW5jb2RlZCB2YWx1ZSwNCndoaWNoIGZpcnN0IGRpZmZlcnMgYXQgdGhl IDExdGggb2N0ZXQ6DQoNCg0KICAgIDEuIENvbnRlbnRUeXBlICAgKDwzMCAxNT4gMDYwOTJBODY0 ODg2RjcwZDAxMDlbMDNdLi4pDQoNCiAgDQogICAgMi4gTWVzc2FnZURpZ2VzdCAoPDMwIDJGPiAw NjA5MkE4NjQ4ODZGNzBkMDEwOVswNF0uLikNCiAgDQoNCiAgICAzLiBTaWduaW5nVGltZSAgICg8 MzAgMUM+IDA2MDkyQTg2NDg4NkY3MGQwMTA5WzA1XS4uKQ0KDQoNCkJ1dCB3ZSBmaW5kIHRoYXQg YXMgZW5jb2RlZCwgdGhleSBhcmUgb3JkZXJlZCBhczoNCg0KDQogICAgMS4gQ29udGVudFR5cGUg ICAoPDMwIFsxNV0+IC4uKQ0KICANCg0KICAgIDIuIFNpZ25pbmdUaW1lICAgKDwzMCBbMUNdPiAu LikNCg0KICANCiAgICAzLiBNZXNzYWdlRGlnZXN0ICg8MzAgWzJGXT4gLi4pDQoNCg0KaS5lLiBz b3J0aW5nIHRoZSBTZXQtb2YgY29tcG9uZW50IHR5cGVzIGJ5IHRoZWlyIERFUiBlbmNvZGluZywg aW5jbHVkaW5nDQp0YWcgYW5kIGxlbmd0aCAoMTUgPCAyOCA8IDQ3KS4gRGVzcGl0ZSBiZWluZyBp biB2aW9sYXRpb24gb2YgdGhlDQpzcGVjaWZpY2F0aW9uKHMpLCB0aGlzIGlzIHNpbXBsZXIgZnJv bSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSBhbmQNCnNlZW1zIHRvIGhhdmUgYmVjb21l IGEgZGUgZmFjdG8gc3RhbmRhcmQuDQoNCg0KTXkgcXVlc3Rpb24gaXM6IEZvciB0aGUgcHVycG9z ZSBvZiBkZXRlcm1pbmluZyBpZiBhbiBvYmplY3QgY29uZm9ybXMgdG8NCnRoZSBSRkMzODUyIGFu ZC9vciBSRkM1NjUyIENNUyBwcm9maWxlLCBzaG91bGQgd2UgY29uc2lkZXIgdGhlIHNlY29uZA0K U2lnbmVkQXR0cmlidXRlcyBTZXQtb2YgZW5jb2RpbmcgbWV0aG9kIGNvbXBsaWFudD8NCg0KDQpU aGFua3MsDQoNCg0KSmFjb2IgRGlsbGVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwa2l4IG1haWxpbmcgbGlzdA0KcGtpeEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4DQo= From nobody Mon Apr 21 21:42:03 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAA1A0065 for ; Mon, 21 Apr 2014 21:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6vDgwb6TnLp for ; Mon, 21 Apr 2014 21:41:58 -0700 (PDT) Received: from p02c12o148.mxlogic.net (p02c12o148.mxlogic.net [208.65.145.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2309B1A0057 for ; Mon, 21 Apr 2014 21:41:58 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB027.mail.lan) by p02c12o148.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id 113f5535.2b557f02a940.28985.00-598.64422.p02c12o148.mxlogic.net (envelope-from ); Mon, 21 Apr 2014 22:41:53 -0600 (MDT) X-MXL-Hash: 5355f3113e4b7c8a-4888c4b8deb8db459ace1a704204babc07c5fd4e Received: from unknown [69.25.75.234] (EHLO HUB027.mail.lan) by p02c12o148.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id 903f5535.0.28973.00-385.64398.p02c12o148.mxlogic.net (envelope-from ); Mon, 21 Apr 2014 22:41:48 -0600 (MDT) X-MXL-Hash: 5355f30c6dfbf5c3-26bd5a6f310b2d55d2920c9bae371df653ee43e2 Received: from MAILR001.mail.lan ([10.110.18.28]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Tue, 22 Apr 2014 00:40:34 -0400 From: Jacob Dilles To: "Manger, James" , "pkix@ietf.org" Date: Tue, 22 Apr 2014 00:41:43 -0400 Thread-Topic: RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes Thread-Index: Ac9d5S/Zu/J3LlGCTjm34/NcPHr0tg== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E115452B12CD@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115452B12CD@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=UdzfSciN c=1 sm=1 tr=0 a=PkGQAut8NMstkBiKWxohFA==] X-AnalysisOut: [:17 a=VoY0yXNOFCIA:10 a=VAHCr3vHLGEA:10 a=aRBQtKuRrKEA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=XW0vzNQbW2AA:10 a=MwhnZbRVAAAA:8 a=YlV] X-AnalysisOut: [TAMxIAAAA:8 a=IzOhgYWHAAAA:8 a=48vgC7mUAAAA:8 a=PcIPu3yHja] X-AnalysisOut: [4xqHikjT4A:9 a=muode7mRwXIgaLur:21 a=lVGGXZN0Tm7Dftae:21 a] X-AnalysisOut: [=Spabb166XhwA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014042140); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.25.75.234] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/qPWxMuhaziTA3Pp5B-3eV-0irQE Subject: Re: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 04:42:01 -0000 VGhhbmtzIEphbWVzLA0KDQoNCk1heWJlIEknbSBiZWluZyBkZW5zZSwgYnV0IChjb21tZW50cyBp bmxpbmUpOg0KDQoNCk9uIDQvMjEvMTQgMTA6MTkgUE0sICJNYW5nZXIsIEphbWVzIiA8SmFtZXMu SC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4NCndyb3RlOg0KDQo+SmFjb2IsDQo+DQo+VGhlIHRh ZyAmIGxlbmd0aCBhcmUgbm90IGV4Y2x1ZGVkIHdoZW4gc29ydGluZyBhIFNFVCBPRiBlbGVtZW50 cy4gWW91IGFyZQ0KPm1pc3JlYWRpbmcgdGhlIHNwZWNzLg0KPg0KPlRoZSAxOTg4IHRleHQgbWln aHQgaGF2ZSBiZWVuIGEgYml0IHVuY2xlYXIgYnkgc2F5aW5nICJ0aGUgY29tcG9uZW50cyAuLg0K Pm9jdGV0IHZhbHVlIi4gVGhlIDIwMDIgdGV4dCBpcyBjcnlzdGFsIGNsZWFyOiAiZW5jb2Rpbmdz IiBhcmUgY29tcGFyZWQuDQo+QW4gZW5jb2RpbmcgaW5jbHVkZXMgdGFnLWxlbmd0aC12YWx1ZS4g SXQgbWFrZXMgbm8gc2Vuc2UgdG8gZXhjbHVkZSB0YWcgJg0KPmxlbmd0aCBhcyB0aGVuIHNvcnRp bmcgd291bGQgbm90IGJlIHVuaXF1ZSB3aGVuIHRoZSB2YWx1ZXMgb2YgdHdvDQo+Y29tcG9uZW50 cyB3ZXJlIGVtcHR5IChvciBpZGVudGljYWwpLg0KDQoNClNldC1vZiB0eXBlIGlzIGRlZmluZWQg dG8gaGF2ZSBhbGwgY29tcG9uZW50cyBvZiB0aGUgc2FtZSB0eXBlLCBzbyB0aGUNCnRhZ3Mgd2ls bCBhbHdheXMgYmUgdGhlIHNhbWUsIGFuZCB0d28gY29tcG9uZW50IHR5cGVzIHdpdGggZW1wdHkg b3INCmlkZW50aWNhbCB2YWx1ZXMgaGF2ZSBleGFjdGx5IG9uZSBlbmNvZGluZywgbm8gc29ydGlu ZyByZXF1aXJlZC4gRm9yDQpleGFtcGxlOg0KDQoNCkEgOjo9IElOVEVHRVIgMQ0KDQpCIDo6PSBJ TlRFR0VSIDENCg0KUzEgOjo9IFNFVCBPRiBJTlRFR0VSIHtBIEJ9DQoNClMyIDo6PSBTRVQgT0Yg SU5URUdFUiB7QiBBfQ0KDQoNClMxIGFuZCBTMiBhcmUgaW5kaXN0aW5ndWlzaGFibGUgezEgMX0g YW5kIHRodXMgaGF2ZSBhIHVuaXF1ZSBlbmNvZGluZyAoMzENCjA0IDAyIDAxIDAyIDAxKS4gVGhp cyBpcyB0cnVlIGZvciBhbnkgbGVuZ3RoIChpbmNsdWRpbmcgZW1wdHkpIGFuZCBhbnkNCm51bWJl ciBvZiByZXBlYXRlZCB2YWx1ZXMgLSBJJ20gbm90IHN1cmUgd2hhdCB0aGUgcmVsZXZhbmNlIGlz IGhlcmUuDQoNCg0KPiBUaGUgdGFsayBvZiBwYWRkaW5nIGp1c3QgbWFrZXMgc3VyZSB0aGF0IHdo ZW4gY29tcGFyaW5nIGVuY29kaW5ncyBvZg0KPmRpZmZlcmVudCBsZW5ndGhzIHRoZWlyIGZpcnN0 IGJ5dGVzIGFyZSBhbGlnbmVkLCBub3QgdGhlaXIgbGFzdCBieXRlcy4NCg0KDQpXaHkgd291bGQg eW91IG5lZWQgcGFkZGluZyB3aGVuIGNvbXBhcmluZyBERVIgdGFnLWxlbmd0aC12YWx1ZSBlbmNv ZGluZ3MNCnRoYXQgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Rocz8NCg0KDQoqIEZvciBjb21wYXJpc29u IGJldHdlZW4gdHdvIGNvbXBvbmVudHMgZW5jb2RlZCB3aXRoIHNob3J0LWZvcm0gbGVuZ3RoDQoo MC0xMjcgb2N0ZXRzKSwgY2xlYXJseSB0aGUgY29tcGFyaXNvbiB3aWxsIGVuZCBhdCB0aGUgKG9u bHkpIGxlbmd0aA0Kb2N0ZXQsIG5vIHBhZGRpbmcgcmVxdWlyZWQuDQoNCiogRm9yIGNvbXBhcmlz b24gYmV0d2VlbiBhIHNob3J0LWZvcm0gYW5kIGxvbmctZm9ybSBsZW5ndGhzLCB0aGUNCmNvbXBh cmlzb24gd2lsbCBlbmQgd2l0aCB0aGUgZmlyc3QgbGVuZ3RoIG9jdGV0LCBhcyAxeHh4eHh4eCA+ IDB4eHh4eHh4Lg0KTm8gcGFkZGluZyByZXF1aXJlZC4NCg0KKiBGb3IgY29tcGFyaXNvbiBiZXR3 ZWVuIHR3byBsb25nLWZvcm0gbGVuZ3RocyB0aGF0IHJlcXVpcmUgYSBkaWZmZXJlbnQNCm51bWJl ciBvZiBleHRlbmQtb2N0ZXRzLCB0aGUgY29tcGFyaXNvbiB3aWxsIGVuZCB3aXRoIHRoZSBmaXJz dCBvY3RldA0Kc2luY2UgaXQgaW5jbHVkZXMgdGhlIG51bWJlciBvZiBsZW5ndGgtZXh0ZW5kIG9j dGV0cyAoZS5nLiBUVCBbODJdIHh4IHh4DQpWcy4gVFQgWzgzXSB4eCB4eCB4eCkuIE5vIHBhZGRp bmcgcmVxdWlyZWQuDQoNCiogRm9yIGNvbXBhcmlzb24gYmV0d2VlbiB0d28gbG9uZy1mb3JtIGxl bmd0aHMgdGhhdCByZXF1aXJlIHRoZSBzYW1lDQpudW1iZXIgb2YgbGVuZ3RoLWV4dGVuZCBvY3Rl dHMsIHRoZSBjb21wYXJpc29uIHdpbGwgZW5kIGF0IHRoZSBkaWZmZXJpbmcNCmxlbmd0aC1leHRl bmQgb2N0ZXQsIG9mIHdoaWNoIHRoZXJlIGFyZSB0aGUgc2FtZSBxdWFudGl0eS4gTm8gcGFkZGlu Zw0KcmVxdWlyZWQuIA0KDQpQZXJoYXBzIHlvdSBoYXZlIGEgY291bnRlcmV4YW1wbGU/DQoNCg0K Pg0KPi0tDQo+SmFtZXMgTWFuZ2VyDQoNCg0KSWYgdGhlIGF1dGhvcnMgaGFkIGludGVuZGVkIGxl bmd0aHMgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIGNvbXBhcmlzb24sIGl0DQp3b3VsZCBiZSB3b3Jk ZWQgInNoYWxsIGFwcGVhciBpbiBhc2NlbmRpbmcgb3JkZXIsIHNob3J0ZXIgY29tcG9uZW50cw0K Zmlyc3QsIHdpdGggdmFsdWVzIG9mIGVxdWFsIGxlbmd0aCBiZWluZyBjb21wYXJlZCBhcyBvY3Rl dCBzdHJpbmdzIiB3aGljaA0Kd291bGQgYmUgY29tcHV0YXRpb25hbGx5IGNoZWFwZXI7IHlldCB0 aGV5IHdlbnQgb3V0IG9mIHRoZWlyIHdheSB0bw0Kc3BlY2lmeSB0aGUgemVyby1wYWRkaW5nIGFs Z29yaXRobS4gVGhlIG9ubHkgd2F5IHRoaXMgYWxnb3JpdGhtIGdldHMgdXNlZA0KaXMgaWYgeW91 IGlnbm9yZSB0aGUgbGVuZ3RoIG9mIHRoZSBlbmNvZGVkIFNldC1vZiBlbGVtZW50DQp0YWctbGVu Z3RoLXZhbHVlLiAgDQoNCgkJCQkNCgkJCQ0KCQkNCgkNCg0KSmFjb2IgRGlsbGVzDQoNCg0KDQpQ UyBTb3J0aW5nIGJ5IHplcm8tcGFkZGVkICp2YWx1ZSogZW5jb2RpbmcgbWFrZXMgc2Vuc2UgYmVj YXVzZSwgZm9yDQpleGFtcGxlLCBhIFNFVCBPRiBPQkpFQ1QgSURFTlRJRklFUiAob3IgQWxnb3Jp dGhtSWRlbnRpZmllciwgb3IgQXR0cmlidXRlLA0KZXRjLikgd2lsbCBzb3J0IGJ5IGFyYy4NCg0K DQoNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHBraXggW21haWx0bzpw a2l4LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYWNvYiBEaWxsZXMNCj5TZW50OiBU dWVzZGF5LCAyMiBBcHJpbCAyMDE0IDEwOjU5IEFNDQo+VG86IHBraXhAaWV0Zi5vcmcNCj5TdWJq ZWN0OiBbcGtpeF0gUkZDMzg1Mi9SRkM1NjUyIENNUyBERVIgU2V0LW9mIGVuY29kaW5nIGluDQo+ U2lnbmVkQXR0cmlidXRlcw0KPg0KPldlIGFyZSBkb2luZyBpbi1kZXB0aCBjb25mb3JtYW5jZSB2 YWxpZGF0aW9uIG9mIFJGQzMzNjkvNTY1MiBDTVMgb2JqZWN0cw0KPndpdGggU2lnbmVkRGF0YSAo U2VjdGlvbiA1KSBjb250ZW50IHR5cGUuDQo+DQo+DQo+T25lIG9mIHRoZSB0aGluZ3Mgd2UgY2hl Y2sgaXMgc29ydC1vcmRlciBvbiBTZXQtT2YgdHlwZXMsIGFzIGluDQo+DQo+DQo+fCAgICBTaWdu ZWRBdHRyaWJ1dGVzIDo6PSBTRVQgU0laRSAoMS4uTUFYKSBPRiBBdHRyaWJ1dGUNCj4NCj4NCj4g ICAgDQo+d2hpY2ggbXVzdCBiZSBERVIgZW5jb2RlZCBwZXIgU2VjdGlvbiAyIHBnLiAzIG9mIHRo ZSBSRkMuIEFzIHNwZWNpZmllZA0KPmJ5IHRoZSByZWZlcmVuY2UgW0RFUl0sIFguNTA5LTg4IHNl YyA4LjcgKHAxNCk6DQo+DQo+DQo+fCAgIGUpIHRoZSBjb21wb25lbnRzIG9mIGEgU2V0LW9mIHR5 cGUgc2hhbGwgYmUgZW5jb2RlZCBpbiBhc2NlbmRpbmcNCj58ICAgICAgb3JkZXIgb2YgdGhlaXIg b2N0ZXQgdmFsdWU7DQo+DQo+DQo+UGVyIHRoZSB0ZXJtaW5vbG9neSBvZiBYLjIwOSBCRVIsIHRo aXMgaXMgdW5hbWJpZ3VvdXMgaW4gZXhjbHVkaW5nDQo+bGVuZ3RoIGZyb20gdGhlIGNvbXBhcmlz b24gKG5vdCAndGFnJyBub3IgJ2xlbmd0aCcsIG9ubHkgJ3ZhbHVlJyk7DQo+aG93ZXZlciB0aGUg cG9pbnQgd2FzIGNsYXJpZmllZCBsYXRlciBpbiBYLjY5MC0wMjA3IChwMTkpOg0KPg0KPg0KPnwg ICAxMS42IFRoZSBlbmNvZGluZ3Mgb2YgdGhlIGNvbXBvbmVudCB2YWx1ZXMgb2YgYSBzZXQtb2Yg dmFsdWUgc2hhbGwNCj58ICAgICAgICBhcHBlYXIgaW4gYXNjZW5kaW5nIG9yZGVyLCB0aGUgZW5j b2RpbmdzIGJlaW5nIGNvbXBhcmVkIGFzDQo+fCAgICAgICAgb2N0ZXQgc3RyaW5ncyB3aXRoIHRo ZSBzaG9ydGVyIGNvbXBvbmVudHMgYmVpbmcgcGFkZGVkIGF0IHRoZWlyDQo+fCAgICAgICAgdHJh aWxpbmcgZW5kIHdpdGggMC1vY3RldHMuDQo+fA0KPiAgICANCj58ICAgICAgICBOT1RFIKGpIFRo ZSBwYWRkaW5nIG9jdGV0cyBhcmUgZm9yIGNvbXBhcmlzb24gcHVycG9zZXMgb25seQ0KPnwgICAg ICAgIGFuZCBkbyBub3QgYXBwZWFyIGluIHRoZSBlbmNvZGluZ3MuDQo+DQo+DQo+V2hpY2ggaXMg c2ltaWxhciAoY29tcG9uZW50ICd2YWx1ZXMnIC4uICdhc2NlbmRpbmcgb3JkZXInKSwgYnV0IGdv ZXMgb24NCj50byBzcGVjaWZpY2FsbHkgcmVxdWlyZSB0aGF0IGxlbmd0aCBiZSBleGNsdWRlZCBm cm9tIGNvbXBhcmlzb24NCj4ob3RoZXJ3aXNlLCBhIHRyYWlsaW5nLXplcm8gcGFkZGluZyBzY2hl bWUgaXMgdW5uZWNlc3NhcnksDQo+bGV4aWNvZ3JhcGhpY2FsIHNvcnRpbmcgb2YgdGhlIGRlZmlu aXRlLWxlbmd0aCBlbmNvZGluZyBvZiB0eXBlcw0KPndpdGggdGhlIHNhbWUgdGFnIHdpbGwgYWx3 YXlzIHJlc3VsdCBpbiBzaG9ydGVzdC1sZW5ndGgtZmlyc3Qgb3JkZXIpLg0KPg0KPg0KPldlIGhh dmUgbm90aWNlZCBhIGRpc2NyZXBhbmN5IGJldHdlZW4gdGhpcyBzcGVjaWZpY2F0aW9uIGFuZCBt YW55IENNUw0KPm9iamVjdHMsIGJvdGggZm91bmQgaW4gdGhlIHdpbGQgYW5kIHByb2R1Y2VkIGlu IHRlc3Rpbmcgc2V2ZXJhbCBwb3B1bGFyDQo+Y3J5cHRvZ3JhcGhpYyBsaWJyYXJpZXMuDQo+DQo+ DQo+VGhyZWUgY29tbW9uIFNpZ25lZEF0dHJpYnV0ZXMgYXJlIENvbnRlbnRUeXBlICgxMS4xKSwg TWVzc2FnZURpZ2VzdA0KPigxMS4yKSwgYW5kIFNpZ25pbmdUaW1lICgxMS4zKTsgSURFTlRJRklF RCBCWSAxLjIuODQwLjExMzU0OS4xLjkuMywgLjQsDQo+YW5kIC41IHJlc3BlY3RpdmVseSAoZnJv bSBQS0NTOSkuIFBlciBbREVSXSwgZ2l2ZW4gdGhlDQo+Zm9sbG93aW5nIGlucHV0Og0KPg0KPg0K PiAgICBhLiBDb250ZW50VHlwZTogICAyLjIzLjEzNi4xLjEuMQ0KPg0KPiAgICBiLiBNZXNzYWdl RGlnZXN0Og0KPmQyMWMxMWVlNjdlMjAwZmQ0NTJiNTg3Y2MzYmM1Y2I0YjBhYjdhOTJjMTYzODlm Y2U5NmM3YTc5YWE3MTRlYmMNCj4NCj4gICAgYy4gU2lnbmluZ1RpbWU6ICAgMDcwMTMxMjAzMDE2 Wg0KPg0KPg0KPldlIHNob3VsZCBlbmNvZGUgdGhlIFNldC1vZiBBdHRyaWJ1dGVzIG9yZGVyZWQg YnkgdGhlaXIgZW5jb2RlZCB2YWx1ZSwNCj53aGljaCBmaXJzdCBkaWZmZXJzIGF0IHRoZSAxMXRo IG9jdGV0Og0KPg0KPg0KPiAgICAxLiBDb250ZW50VHlwZSAgICg8MzAgMTU+IDA2MDkyQTg2NDg4 NkY3MGQwMTA5WzAzXS4uKQ0KPg0KPiAgDQo+ICAgIDIuIE1lc3NhZ2VEaWdlc3QgKDwzMCAyRj4g MDYwOTJBODY0ODg2RjcwZDAxMDlbMDRdLi4pDQo+ICANCj4NCj4gICAgMy4gU2lnbmluZ1RpbWUg ICAoPDMwIDFDPiAwNjA5MkE4NjQ4ODZGNzBkMDEwOVswNV0uLikNCj4NCj4NCj5CdXQgd2UgZmlu ZCB0aGF0IGFzIGVuY29kZWQsIHRoZXkgYXJlIG9yZGVyZWQgYXM6DQo+DQo+DQo+ICAgIDEuIENv bnRlbnRUeXBlICAgKDwzMCBbMTVdPiAuLikNCj4gIA0KPg0KPiAgICAyLiBTaWduaW5nVGltZSAg ICg8MzAgWzFDXT4gLi4pDQo+DQo+ICANCj4gICAgMy4gTWVzc2FnZURpZ2VzdCAoPDMwIFsyRl0+ IC4uKQ0KPg0KPg0KPmkuZS4gc29ydGluZyB0aGUgU2V0LW9mIGNvbXBvbmVudCB0eXBlcyBieSB0 aGVpciBERVIgZW5jb2RpbmcsIGluY2x1ZGluZw0KPnRhZyBhbmQgbGVuZ3RoICgxNSA8IDI4IDwg NDcpLiBEZXNwaXRlIGJlaW5nIGluIHZpb2xhdGlvbiBvZiB0aGUNCj5zcGVjaWZpY2F0aW9uKHMp LCB0aGlzIGlzIHNpbXBsZXIgZnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSBhbmQN Cj5zZWVtcyB0byBoYXZlIGJlY29tZSBhIGRlIGZhY3RvIHN0YW5kYXJkLg0KPg0KPg0KPk15IHF1 ZXN0aW9uIGlzOiBGb3IgdGhlIHB1cnBvc2Ugb2YgZGV0ZXJtaW5pbmcgaWYgYW4gb2JqZWN0IGNv bmZvcm1zIHRvDQo+dGhlIFJGQzM4NTIgYW5kL29yIFJGQzU2NTIgQ01TIHByb2ZpbGUsIHNob3Vs ZCB3ZSBjb25zaWRlciB0aGUgc2Vjb25kDQo+U2lnbmVkQXR0cmlidXRlcyBTZXQtb2YgZW5jb2Rp bmcgbWV0aG9kIGNvbXBsaWFudD8NCj4NCj4NCj5UaGFua3MsDQo+DQo+DQo+SmFjb2IgRGlsbGVz DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5w a2l4IG1haWxpbmcgbGlzdA0KPnBraXhAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BraXgNCg0K From nobody Mon Apr 21 22:19:26 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A151A0077 for ; Mon, 21 Apr 2014 22:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPxkNKHYSd4D for ; Mon, 21 Apr 2014 22:19:18 -0700 (PDT) Received: from p02c12o148.mxlogic.net (p02c12o148.mxlogic.net [208.65.145.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51F1A006E for ; Mon, 21 Apr 2014 22:19:13 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB028.mail.lan) by p02c12o148.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id acbf5535.0.34327.00-359.75091.p02c12o148.mxlogic.net (envelope-from ); Mon, 21 Apr 2014 23:19:12 -0600 (MDT) X-MXL-Hash: 5355fbd02eb979a2-d2fb8e24aa0d75843892fcc9ce25c92345523cae Received: from MAILR001.mail.lan ([10.110.18.28]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Tue, 22 Apr 2014 01:19:05 -0400 From: Jacob Dilles To: "pkix@ietf.org" , "Manger, James" Date: Tue, 22 Apr 2014 01:19:05 -0400 Thread-Topic: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes Thread-Index: Ac9d6maqWwqagfG6QCiAlHYa3YPsUQ== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E115452B12CD@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=UdzfSciN c=1 sm=1 tr=0 a=PkGQAut8NMstkBiKWxohFA==] X-AnalysisOut: [:17 a=VoY0yXNOFCIA:10 a=o7LmVwG6YlYA:10 a=aRBQtKuRrKEA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=XW0vzNQbW2AA:10 a=MwhnZbRVAAAA:8 a=YlV] X-AnalysisOut: [TAMxIAAAA:8 a=IzOhgYWHAAAA:8 a=48vgC7mUAAAA:8 a=GPIJ7OLBn2] X-AnalysisOut: [1N1pA7DSkA:9 a=oKwfYaQ78OaPly9j:21 a=LLTIP0jry-CDWjr2:21 a] X-AnalysisOut: [=Spabb166XhwA:10 a=gD0CuhlsKQMA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014042141); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.25.75.234] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/rf3L2JBXo8y8DcpMzKnh8vlgzGI Subject: Re: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 05:19:22 -0000 U29ycnksIFNFVCBPRiBJTlRFR0VSIHsxIDF9IGlzIDMxIDA2IDAyIDAxIDAxIDAyIDAxIDAxLiBC aXQgcnVzdHkgb24gdGhlDQpoYW5kLWVuY29kaW5nIDopDQoNCg0KT24gNC8yMi8xNCAxMjo0MSBB TSwgIkphY29iIERpbGxlcyIgPGpkaWxsZXNAbW91bnRhaXJleWdyb3VwLmNvbT4gd3JvdGU6DQoN Cj5UaGFua3MgSmFtZXMsDQo+DQo+DQo+TWF5YmUgSSdtIGJlaW5nIGRlbnNlLCBidXQgKGNvbW1l bnRzIGlubGluZSk6DQo+DQo+DQo+T24gNC8yMS8xNCAxMDoxOSBQTSwgIk1hbmdlciwgSmFtZXMi IDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPg0KPndyb3RlOg0KPg0KPj5KYWNvYiwN Cj4+DQo+PlRoZSB0YWcgJiBsZW5ndGggYXJlIG5vdCBleGNsdWRlZCB3aGVuIHNvcnRpbmcgYSBT RVQgT0YgZWxlbWVudHMuIFlvdSBhcmUNCj4+bWlzcmVhZGluZyB0aGUgc3BlY3MuDQo+Pg0KPj5U aGUgMTk4OCB0ZXh0IG1pZ2h0IGhhdmUgYmVlbiBhIGJpdCB1bmNsZWFyIGJ5IHNheWluZyAidGhl IGNvbXBvbmVudHMgLi4NCj4+b2N0ZXQgdmFsdWUiLiBUaGUgMjAwMiB0ZXh0IGlzIGNyeXN0YWwg Y2xlYXI6ICJlbmNvZGluZ3MiIGFyZSBjb21wYXJlZC4NCj4+QW4gZW5jb2RpbmcgaW5jbHVkZXMg dGFnLWxlbmd0aC12YWx1ZS4gSXQgbWFrZXMgbm8gc2Vuc2UgdG8gZXhjbHVkZSB0YWcgJg0KPj5s ZW5ndGggYXMgdGhlbiBzb3J0aW5nIHdvdWxkIG5vdCBiZSB1bmlxdWUgd2hlbiB0aGUgdmFsdWVz IG9mIHR3bw0KPj5jb21wb25lbnRzIHdlcmUgZW1wdHkgKG9yIGlkZW50aWNhbCkuDQo+DQo+DQo+ U2V0LW9mIHR5cGUgaXMgZGVmaW5lZCB0byBoYXZlIGFsbCBjb21wb25lbnRzIG9mIHRoZSBzYW1l IHR5cGUsIHNvIHRoZQ0KPnRhZ3Mgd2lsbCBhbHdheXMgYmUgdGhlIHNhbWUsIGFuZCB0d28gY29t cG9uZW50IHR5cGVzIHdpdGggZW1wdHkgb3INCj5pZGVudGljYWwgdmFsdWVzIGhhdmUgZXhhY3Rs eSBvbmUgZW5jb2RpbmcsIG5vIHNvcnRpbmcgcmVxdWlyZWQuIEZvcg0KPmV4YW1wbGU6DQo+DQo+ DQo+QSA6Oj0gSU5URUdFUiAxDQo+DQo+QiA6Oj0gSU5URUdFUiAxDQo+DQo+UzEgOjo9IFNFVCBP RiBJTlRFR0VSIHtBIEJ9DQo+DQo+UzIgOjo9IFNFVCBPRiBJTlRFR0VSIHtCIEF9DQo+DQo+DQo+ UzEgYW5kIFMyIGFyZSBpbmRpc3Rpbmd1aXNoYWJsZSB7MSAxfSBhbmQgdGh1cyBoYXZlIGEgdW5p cXVlIGVuY29kaW5nICgzMQ0KPjA0IDAyIDAxIDAyIDAxKS4gVGhpcyBpcyB0cnVlIGZvciBhbnkg bGVuZ3RoIChpbmNsdWRpbmcgZW1wdHkpIGFuZCBhbnkNCj5udW1iZXIgb2YgcmVwZWF0ZWQgdmFs dWVzIC0gSSdtIG5vdCBzdXJlIHdoYXQgdGhlIHJlbGV2YW5jZSBpcyBoZXJlLg0KPg0KPg0KPj4g VGhlIHRhbGsgb2YgcGFkZGluZyBqdXN0IG1ha2VzIHN1cmUgdGhhdCB3aGVuIGNvbXBhcmluZyBl bmNvZGluZ3Mgb2YNCj4+ZGlmZmVyZW50IGxlbmd0aHMgdGhlaXIgZmlyc3QgYnl0ZXMgYXJlIGFs aWduZWQsIG5vdCB0aGVpciBsYXN0IGJ5dGVzLg0KPg0KPg0KPldoeSB3b3VsZCB5b3UgbmVlZCBw YWRkaW5nIHdoZW4gY29tcGFyaW5nIERFUiB0YWctbGVuZ3RoLXZhbHVlIGVuY29kaW5ncw0KPnRo YXQgaGF2ZSBkaWZmZXJlbnQgbGVuZ3Rocz8NCj4NCj4NCj4qIEZvciBjb21wYXJpc29uIGJldHdl ZW4gdHdvIGNvbXBvbmVudHMgZW5jb2RlZCB3aXRoIHNob3J0LWZvcm0gbGVuZ3RoDQo+KDAtMTI3 IG9jdGV0cyksIGNsZWFybHkgdGhlIGNvbXBhcmlzb24gd2lsbCBlbmQgYXQgdGhlIChvbmx5KSBs ZW5ndGgNCj5vY3RldCwgbm8gcGFkZGluZyByZXF1aXJlZC4NCj4NCj4qIEZvciBjb21wYXJpc29u IGJldHdlZW4gYSBzaG9ydC1mb3JtIGFuZCBsb25nLWZvcm0gbGVuZ3RocywgdGhlDQo+Y29tcGFy aXNvbiB3aWxsIGVuZCB3aXRoIHRoZSBmaXJzdCBsZW5ndGggb2N0ZXQsIGFzIDF4eHh4eHh4ID4g MHh4eHh4eHguDQo+Tm8gcGFkZGluZyByZXF1aXJlZC4NCj4NCj4qIEZvciBjb21wYXJpc29uIGJl dHdlZW4gdHdvIGxvbmctZm9ybSBsZW5ndGhzIHRoYXQgcmVxdWlyZSBhIGRpZmZlcmVudA0KPm51 bWJlciBvZiBleHRlbmQtb2N0ZXRzLCB0aGUgY29tcGFyaXNvbiB3aWxsIGVuZCB3aXRoIHRoZSBm aXJzdCBvY3RldA0KPnNpbmNlIGl0IGluY2x1ZGVzIHRoZSBudW1iZXIgb2YgbGVuZ3RoLWV4dGVu ZCBvY3RldHMgKGUuZy4gVFQgWzgyXSB4eCB4eA0KPlZzLiBUVCBbODNdIHh4IHh4IHh4KS4gTm8g cGFkZGluZyByZXF1aXJlZC4NCj4NCj4qIEZvciBjb21wYXJpc29uIGJldHdlZW4gdHdvIGxvbmct Zm9ybSBsZW5ndGhzIHRoYXQgcmVxdWlyZSB0aGUgc2FtZQ0KPm51bWJlciBvZiBsZW5ndGgtZXh0 ZW5kIG9jdGV0cywgdGhlIGNvbXBhcmlzb24gd2lsbCBlbmQgYXQgdGhlIGRpZmZlcmluZw0KPmxl bmd0aC1leHRlbmQgb2N0ZXQsIG9mIHdoaWNoIHRoZXJlIGFyZSB0aGUgc2FtZSBxdWFudGl0eS4g Tm8gcGFkZGluZw0KPnJlcXVpcmVkLiANCj4NCj5QZXJoYXBzIHlvdSBoYXZlIGEgY291bnRlcmV4 YW1wbGU/DQo+DQo+DQo+Pg0KPj4tLQ0KPj5KYW1lcyBNYW5nZXINCj4NCj4NCj5JZiB0aGUgYXV0 aG9ycyBoYWQgaW50ZW5kZWQgbGVuZ3RocyB0byBiZSBpbmNsdWRlZCBpbiB0aGUgY29tcGFyaXNv biwgaXQNCj53b3VsZCBiZSB3b3JkZWQgInNoYWxsIGFwcGVhciBpbiBhc2NlbmRpbmcgb3JkZXIs IHNob3J0ZXIgY29tcG9uZW50cw0KPmZpcnN0LCB3aXRoIHZhbHVlcyBvZiBlcXVhbCBsZW5ndGgg YmVpbmcgY29tcGFyZWQgYXMgb2N0ZXQgc3RyaW5ncyIgd2hpY2gNCj53b3VsZCBiZSBjb21wdXRh dGlvbmFsbHkgY2hlYXBlcjsgeWV0IHRoZXkgd2VudCBvdXQgb2YgdGhlaXIgd2F5IHRvDQo+c3Bl Y2lmeSB0aGUgemVyby1wYWRkaW5nIGFsZ29yaXRobS4gVGhlIG9ubHkgd2F5IHRoaXMgYWxnb3Jp dGhtIGdldHMgdXNlZA0KPmlzIGlmIHlvdSBpZ25vcmUgdGhlIGxlbmd0aCBvZiB0aGUgZW5jb2Rl ZCBTZXQtb2YgZWxlbWVudA0KPnRhZy1sZW5ndGgtdmFsdWUuIA0KPg0KPgkJCQkNCj4JCQkNCj4J CQ0KPgkNCj4NCj5KYWNvYiBEaWxsZXMNCj4NCj4NCj4NCj5QUyBTb3J0aW5nIGJ5IHplcm8tcGFk ZGVkICp2YWx1ZSogZW5jb2RpbmcgbWFrZXMgc2Vuc2UgYmVjYXVzZSwgZm9yDQo+ZXhhbXBsZSwg YSBTRVQgT0YgT0JKRUNUIElERU5USUZJRVIgKG9yIEFsZ29yaXRobUlkZW50aWZpZXIsIG9yIEF0 dHJpYnV0ZSwNCj5ldGMuKSB3aWxsIHNvcnQgYnkgYXJjLg0KPg0KPg0KPg0KPj4NCj4+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogcGtpeCBbbWFpbHRvOnBraXgtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphY29iIERpbGxlcw0KPj5TZW50OiBUdWVzZGF5LCAyMiBB cHJpbCAyMDE0IDEwOjU5IEFNDQo+PlRvOiBwa2l4QGlldGYub3JnDQo+PlN1YmplY3Q6IFtwa2l4 XSBSRkMzODUyL1JGQzU2NTIgQ01TIERFUiBTZXQtb2YgZW5jb2RpbmcgaW4NCj4+U2lnbmVkQXR0 cmlidXRlcw0KPj4NCj4+V2UgYXJlIGRvaW5nIGluLWRlcHRoIGNvbmZvcm1hbmNlIHZhbGlkYXRp b24gb2YgUkZDMzM2OS81NjUyIENNUyBvYmplY3RzDQo+PndpdGggU2lnbmVkRGF0YSAoU2VjdGlv biA1KSBjb250ZW50IHR5cGUuDQo+Pg0KPj4NCj4+T25lIG9mIHRoZSB0aGluZ3Mgd2UgY2hlY2sg aXMgc29ydC1vcmRlciBvbiBTZXQtT2YgdHlwZXMsIGFzIGluDQo+Pg0KPj4NCj4+fCAgICBTaWdu ZWRBdHRyaWJ1dGVzIDo6PSBTRVQgU0laRSAoMS4uTUFYKSBPRiBBdHRyaWJ1dGUNCj4+DQo+Pg0K Pj4gICAgDQo+PndoaWNoIG11c3QgYmUgREVSIGVuY29kZWQgcGVyIFNlY3Rpb24gMiBwZy4gMyBv ZiB0aGUgUkZDLiBBcyBzcGVjaWZpZWQNCj4+YnkgdGhlIHJlZmVyZW5jZSBbREVSXSwgWC41MDkt ODggc2VjIDguNyAocDE0KToNCj4+DQo+Pg0KPj58ICAgZSkgdGhlIGNvbXBvbmVudHMgb2YgYSBT ZXQtb2YgdHlwZSBzaGFsbCBiZSBlbmNvZGVkIGluIGFzY2VuZGluZw0KPj58ICAgICAgb3JkZXIg b2YgdGhlaXIgb2N0ZXQgdmFsdWU7DQo+Pg0KPj4NCj4+UGVyIHRoZSB0ZXJtaW5vbG9neSBvZiBY LjIwOSBCRVIsIHRoaXMgaXMgdW5hbWJpZ3VvdXMgaW4gZXhjbHVkaW5nDQo+Pmxlbmd0aCBmcm9t IHRoZSBjb21wYXJpc29uIChub3QgJ3RhZycgbm9yICdsZW5ndGgnLCBvbmx5ICd2YWx1ZScpOw0K Pj5ob3dldmVyIHRoZSBwb2ludCB3YXMgY2xhcmlmaWVkIGxhdGVyIGluIFguNjkwLTAyMDcgKHAx OSk6DQo+Pg0KPj4NCj4+fCAgIDExLjYgVGhlIGVuY29kaW5ncyBvZiB0aGUgY29tcG9uZW50IHZh bHVlcyBvZiBhIHNldC1vZiB2YWx1ZSBzaGFsbA0KPj58ICAgICAgICBhcHBlYXIgaW4gYXNjZW5k aW5nIG9yZGVyLCB0aGUgZW5jb2RpbmdzIGJlaW5nIGNvbXBhcmVkIGFzDQo+PnwgICAgICAgIG9j dGV0IHN0cmluZ3Mgd2l0aCB0aGUgc2hvcnRlciBjb21wb25lbnRzIGJlaW5nIHBhZGRlZCBhdCB0 aGVpcg0KPj58ICAgICAgICB0cmFpbGluZyBlbmQgd2l0aCAwLW9jdGV0cy4NCj4+fA0KPj4gICAg DQo+PnwgICAgICAgIE5PVEUgoakgVGhlIHBhZGRpbmcgb2N0ZXRzIGFyZSBmb3IgY29tcGFyaXNv biBwdXJwb3NlcyBvbmx5DQo+PnwgICAgICAgIGFuZCBkbyBub3QgYXBwZWFyIGluIHRoZSBlbmNv ZGluZ3MuDQo+Pg0KPj4NCj4+V2hpY2ggaXMgc2ltaWxhciAoY29tcG9uZW50ICd2YWx1ZXMnIC4u ICdhc2NlbmRpbmcgb3JkZXInKSwgYnV0IGdvZXMgb24NCj4+dG8gc3BlY2lmaWNhbGx5IHJlcXVp cmUgdGhhdCBsZW5ndGggYmUgZXhjbHVkZWQgZnJvbSBjb21wYXJpc29uDQo+PihvdGhlcndpc2Us IGEgdHJhaWxpbmctemVybyBwYWRkaW5nIHNjaGVtZSBpcyB1bm5lY2Vzc2FyeSwNCj4+bGV4aWNv Z3JhcGhpY2FsIHNvcnRpbmcgb2YgdGhlIGRlZmluaXRlLWxlbmd0aCBlbmNvZGluZyBvZiB0eXBl cw0KPj53aXRoIHRoZSBzYW1lIHRhZyB3aWxsIGFsd2F5cyByZXN1bHQgaW4gc2hvcnRlc3QtbGVu Z3RoLWZpcnN0IG9yZGVyKS4NCj4+DQo+Pg0KPj5XZSBoYXZlIG5vdGljZWQgYSBkaXNjcmVwYW5j eSBiZXR3ZWVuIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgbWFueSBDTVMNCj4+b2JqZWN0cywgYm90 aCBmb3VuZCBpbiB0aGUgd2lsZCBhbmQgcHJvZHVjZWQgaW4gdGVzdGluZyBzZXZlcmFsIHBvcHVs YXINCj4+Y3J5cHRvZ3JhcGhpYyBsaWJyYXJpZXMuDQo+Pg0KPj4NCj4+VGhyZWUgY29tbW9uIFNp Z25lZEF0dHJpYnV0ZXMgYXJlIENvbnRlbnRUeXBlICgxMS4xKSwgTWVzc2FnZURpZ2VzdA0KPj4o MTEuMiksIGFuZCBTaWduaW5nVGltZSAoMTEuMyk7IElERU5USUZJRUQgQlkgMS4yLjg0MC4xMTM1 NDkuMS45LjMsIC40LA0KPj5hbmQgLjUgcmVzcGVjdGl2ZWx5IChmcm9tIFBLQ1M5KS4gUGVyIFtE RVJdLCBnaXZlbiB0aGUNCj4+Zm9sbG93aW5nIGlucHV0Og0KPj4NCj4+DQo+PiAgICBhLiBDb250 ZW50VHlwZTogICAyLjIzLjEzNi4xLjEuMQ0KPj4NCj4+ICAgIGIuIE1lc3NhZ2VEaWdlc3Q6DQo+ PmQyMWMxMWVlNjdlMjAwZmQ0NTJiNTg3Y2MzYmM1Y2I0YjBhYjdhOTJjMTYzODlmY2U5NmM3YTc5 YWE3MTRlYmMNCj4+DQo+PiAgICBjLiBTaWduaW5nVGltZTogICAwNzAxMzEyMDMwMTZaDQo+Pg0K Pj4NCj4+V2Ugc2hvdWxkIGVuY29kZSB0aGUgU2V0LW9mIEF0dHJpYnV0ZXMgb3JkZXJlZCBieSB0 aGVpciBlbmNvZGVkIHZhbHVlLA0KPj53aGljaCBmaXJzdCBkaWZmZXJzIGF0IHRoZSAxMXRoIG9j dGV0Og0KPj4NCj4+DQo+PiAgICAxLiBDb250ZW50VHlwZSAgICg8MzAgMTU+IDA2MDkyQTg2NDg4 NkY3MGQwMTA5WzAzXS4uKQ0KPj4NCj4+ICANCj4+ICAgIDIuIE1lc3NhZ2VEaWdlc3QgKDwzMCAy Rj4gMDYwOTJBODY0ODg2RjcwZDAxMDlbMDRdLi4pDQo+PiAgDQo+Pg0KPj4gICAgMy4gU2lnbmlu Z1RpbWUgICAoPDMwIDFDPiAwNjA5MkE4NjQ4ODZGNzBkMDEwOVswNV0uLikNCj4+DQo+Pg0KPj5C dXQgd2UgZmluZCB0aGF0IGFzIGVuY29kZWQsIHRoZXkgYXJlIG9yZGVyZWQgYXM6DQo+Pg0KPj4N Cj4+ICAgIDEuIENvbnRlbnRUeXBlICAgKDwzMCBbMTVdPiAuLikNCj4+ICANCj4+DQo+PiAgICAy LiBTaWduaW5nVGltZSAgICg8MzAgWzFDXT4gLi4pDQo+Pg0KPj4gIA0KPj4gICAgMy4gTWVzc2Fn ZURpZ2VzdCAoPDMwIFsyRl0+IC4uKQ0KPj4NCj4+DQo+PmkuZS4gc29ydGluZyB0aGUgU2V0LW9m IGNvbXBvbmVudCB0eXBlcyBieSB0aGVpciBERVIgZW5jb2RpbmcsIGluY2x1ZGluZw0KPj50YWcg YW5kIGxlbmd0aCAoMTUgPCAyOCA8IDQ3KS4gRGVzcGl0ZSBiZWluZyBpbiB2aW9sYXRpb24gb2Yg dGhlDQo+PnNwZWNpZmljYXRpb24ocyksIHRoaXMgaXMgc2ltcGxlciBmcm9tIGFuIGltcGxlbWVu dGF0aW9uIHBlcnNwZWN0aXZlIGFuZA0KPj5zZWVtcyB0byBoYXZlIGJlY29tZSBhIGRlIGZhY3Rv IHN0YW5kYXJkLg0KPj4NCj4+DQo+Pk15IHF1ZXN0aW9uIGlzOiBGb3IgdGhlIHB1cnBvc2Ugb2Yg ZGV0ZXJtaW5pbmcgaWYgYW4gb2JqZWN0IGNvbmZvcm1zIHRvDQo+PnRoZSBSRkMzODUyIGFuZC9v ciBSRkM1NjUyIENNUyBwcm9maWxlLCBzaG91bGQgd2UgY29uc2lkZXIgdGhlIHNlY29uZA0KPj5T aWduZWRBdHRyaWJ1dGVzIFNldC1vZiBlbmNvZGluZyBtZXRob2QgY29tcGxpYW50Pw0KPj4NCj4+ DQo+PlRoYW5rcywNCj4+DQo+Pg0KPj5KYWNvYiBEaWxsZXMNCj4+DQo+Pl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnBraXggbWFpbGluZyBsaXN0DQo+ PnBraXhAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w a2l4DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5wa2l4IG1haWxpbmcgbGlzdA0KPnBraXhAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg0K From nobody Mon Apr 21 23:15:41 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199B11A0089 for ; Mon, 21 Apr 2014 23:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d13TwQfDY7n1 for ; Mon, 21 Apr 2014 23:15:37 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 76B091A0055 for ; Mon, 21 Apr 2014 23:15:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,901,1389704400"; d="scan'208";a="195553103" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 22 Apr 2014 16:15:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7415"; a="271553243" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 22 Apr 2014 16:15:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 22 Apr 2014 16:15:30 +1000 From: "Manger, James" To: Jacob Dilles , "pkix@ietf.org" Date: Tue, 22 Apr 2014 16:15:29 +1000 Thread-Topic: RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes Thread-Index: Ac9d5S/Zu/J3LlGCTjm34/NcPHr0tgABKngQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1154547FA0C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115452B12CD@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/BAXrayTw7Tw80-q4U4_NixJ1XM8 Subject: Re: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 06:15:39 -0000 PiBTZXQtb2YgdHlwZSBpcyBkZWZpbmVkIHRvIGhhdmUgYWxsIGNvbXBvbmVudHMgb2YgdGhlIHNh bWUgdHlwZSwgc28gdGhlDQo+IHRhZ3Mgd2lsbCBhbHdheXMgYmUgdGhlIHNhbWUsDQoNCk5vLiBU aGUgdHlwZSBjYW4gYmUgYSBDSE9JQ0UsIGluIHdoaWNoIGNhc2UgdGhlIHRhZ3MgY2FuIHZhcnku DQoNCkZvciBpbnN0YW5jZSwNCiAgTGFiZWxzIDo6PSBTRVQgT0YgRGlyZWN0b3J5U3RyaW5nDQp3 aGVyZSBEaXJlY3RvcnlTdHJpbmcgaXMgYSBDSE9JQ0Ugb2YgNSBzdHJpbmcgdHlwZXMgKFRlbGV0 ZXhTdHJpbmcsIFByaW50YWJsZVN0cmluZywgVVRGOFN0cmluZyBldGMpLg0KDQpTbyBoZXJlIChp biBoZXgpIGlzIGEgREVSLWVuY29kaW5nIG9mIGEgU0VUIE9GIERpcmVjdG9yeVN0cmluZyB0aGF0 IGNvbnNpc3RzIG9mIGEgVVRGOFN0cmluZyB3aXRoIHZhbHVlICJhIiBhbmQgYSBQcmludGFibGVT dHJpbmcgd2l0aCB2YWx1ZSAiYSIuDQoNCjMxIDA2DQogICAwQyAwMSA2MQ0KICAgMTMgMDEgNjEN Cg0KLS0NCkphbWVzIE1hbmdlcg0K From nobody Tue Apr 22 06:58:26 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485AB1A047C for ; Tue, 22 Apr 2014 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC5LvPQ4YopU for ; Tue, 22 Apr 2014 06:58:24 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by ietfa.amsl.com (Postfix) with ESMTP id 23D3D1A047B for ; Tue, 22 Apr 2014 06:58:24 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB024.mail.lan) by p01c11o142.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id b7576535.2b53c183b940.114194.00-533.286873.p01c11o142.mxlogic.net (envelope-from ); Tue, 22 Apr 2014 07:58:19 -0600 (MDT) X-MXL-Hash: 5356757b234c1e95-245e410adbf128fee9d4dc818fa901ca59715008 Received: from unknown [69.25.75.234] (EHLO HUB024.mail.lan) by p01c11o142.mxlogic.net(mxl_mta-8.0.0-0) over TLS secured channel with ESMTP id c6576535.0.113998.00-279.286384.p01c11o142.mxlogic.net (envelope-from ); Tue, 22 Apr 2014 07:58:12 -0600 (MDT) X-MXL-Hash: 5356757411322bc4-0ca49e7f9de6fca90ccdef171d932bfe7b4ebdc7 Received: from MAILR001.mail.lan ([10.110.18.28]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 22 Apr 2014 09:58:13 -0400 From: Jacob Dilles To: "Manger, James" , "pkix@ietf.org" Date: Tue, 22 Apr 2014 09:58:02 -0400 Thread-Topic: RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes Thread-Index: Ac9eMubCQ1sSOSR0Qi+i/c1RSl7vbg== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E115452B12CD@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1154547FA0C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1154547FA0C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=No5fcqtJ c=1 sm=1 tr=0 a=PkGQAut8NMstkBiKWxohFA==] X-AnalysisOut: [:17 a=VoY0yXNOFCIA:10 a=VAHCr3vHLGEA:10 a=aRBQtKuRrKEA:10 ] X-AnalysisOut: [a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=MwhnZbRVAAAA:8 a=YlV] X-AnalysisOut: [TAMxIAAAA:8 a=IzOhgYWHAAAA:8 a=AZPwHltKOQw8Od7CltMA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014042212); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.25.75.234] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/w1ShT29wQS7py1UXZVnAFR4MfmY Subject: Re: [pkix] RFC3852/RFC5652 CMS DER Set-of encoding in SignedAttributes X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 13:58:25 -0000 Perfect. I had a feeling I was missing something. Thanks! Jacob Dilles On 4/22/14 2:15 AM, "Manger, James" wrote: >> Set-of type is defined to have all components of the same type, so the >> tags will always be the same, > >No. The type can be a CHOICE, in which case the tags can vary. > >For instance, > Labels ::=3D SET OF DirectoryString >where DirectoryString is a CHOICE of 5 string types (TeletexString, >PrintableString, UTF8String etc). > >So here (in hex) is a DER-encoding of a SET OF DirectoryString that >consists of a UTF8String with value "a" and a PrintableString with value >"a". > >31 06 > 0C 01 61 > 13 01 61 > >-- >James Manger From nobody Wed Apr 23 08:59:47 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAF81A0291; Wed, 23 Apr 2014 08:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKZCAi4KcNhK; Wed, 23 Apr 2014 08:59:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAC51A00CB; Wed, 23 Apr 2014 08:59:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423155941.31190.50343.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 08:59:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/MHuYMPsdTquEVGCoE7Mk0KCxNa8 Cc: Roni Even , pkix@ietf.org, draft-housley-pkix-oids@tools.ietf.org Subject: [pkix] Jari Arkko's No Objection on draft-housley-pkix-oids-02: (with COMMENT) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:59:44 -0000 Jari Arkko has entered the following ballot position for draft-housley-pkix-oids-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-housley-pkix-oids/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- We need to check if the Gen-ART review comments from Roni Even were handled. There was no response. From nobody Wed Apr 23 09:18:02 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1326F1A0291 for ; Wed, 23 Apr 2014 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtEWQisRXQeO; Wed, 23 Apr 2014 09:17:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352221A02A8; Wed, 23 Apr 2014 09:17:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: housley@vigilsec.com, draft-housley-pkix-oids@tools.ietf.org, pkix@ietf.org, stephen.farrell@cs.tcd.ie X-Test-IDTracker: no X-IETF-IDTracker: 5.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140423161753.18398.99378.idtracker@ietfa.amsl.com> Date: Wed, 23 Apr 2014 09:17:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/gbAuBC2A4Zg3Fr1IQJzPMpK11aQ Subject: [pkix] New Version Notification - draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:17:56 -0000 A new version (-03) has been submitted for draft-housley-pkix-oids: http://www.ietf.org/internet-drafts/draft-housley-pkix-oids-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-housley-pkix-oids/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-housley-pkix-oids-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Apr 23 09:22:05 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193E1A02A2 for ; Wed, 23 Apr 2014 09:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPCAw7qex4mm for ; Wed, 23 Apr 2014 09:22:00 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2D1A0221 for ; Wed, 23 Apr 2014 09:22:00 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 169E5F3C031 for ; Wed, 23 Apr 2014 12:21:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id I3TvL3tJhvMZ for ; Wed, 23 Apr 2014 12:21:23 -0400 (EDT) Received: from 156-193.netmundial.org (unknown [199.91.193.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CD0D2F2C079 for ; Wed, 23 Apr 2014 12:21:23 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Apr 2014 12:21:10 -0400 References: <20140423161753.18398.17304.idtracker@ietfa.amsl.com> To: IETF PKIX Message-Id: <57EE9DB9-BA13-4CA9-A8D3-07F3AB9B38F5@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/43B6OYLE8Bmw7ram_pHBFi_GNRs Subject: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:22:03 -0000 I updated this document to do two things: (1) correct an error discovered by Roni Even in his Gen-ART Review. (2) add a sentence to the security considerations about id-pe-nsa. Russ Begin forwarded message: > From: internet-drafts@ietf.org > Date: April 23, 2014 12:17:53 PM EDT > To: "Russ Housley" > Subject: New Version Notification for draft-housley-pkix-oids-03.txt >=20 >=20 > A new version of I-D, draft-housley-pkix-oids-03.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-pkix-oids > Revision: 03 > Title: Object Identifier Registry for the PKIX Working = Group > Document date: 2014-04-23 > Group: Individual Submission > Pages: 30 > URL: = http://www.ietf.org/internet-drafts/draft-housley-pkix-oids-03.txt > Status: = https://datatracker.ietf.org/doc/draft-housley-pkix-oids/ > Htmlized: http://tools.ietf.org/html/draft-housley-pkix-oids-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-housley-pkix-oids-03 >=20 > Abstract: > When the Public-Key Infrastructure using X.509 (PKIX) Working Group > was chartered, an object identifier arc was was allocated by IANA = for > use by that working group. This document describes the object > identifiers that were assigned in that arc, it returns control of > that arc to IANA, and it establishes IANA allocation policies for = any > future assignments within that arc. From nobody Wed Apr 23 09:40:46 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34771A0221 for ; Wed, 23 Apr 2014 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j3wjgrKtWMD for ; Wed, 23 Apr 2014 09:40:41 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with SMTP id B72A71A01E6 for ; Wed, 23 Apr 2014 09:40:41 -0700 (PDT) Received: from [192.168.1.51] (pool-71-171-106-160.clppva.fios.verizon.net [71.171.106.160]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 8AF185802B; Wed, 23 Apr 2014 16:40:50 +0000 (UTC) Message-ID: <5357ED02.2070006@yaanatech.com> Date: Wed, 23 Apr 2014 12:40:34 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Russ Housley , IETF PKIX References: <20140423161753.18398.17304.idtracker@ietfa.amsl.com> <57EE9DB9-BA13-4CA9-A8D3-07F3AB9B38F5@vigilsec.com> In-Reply-To: <57EE9DB9-BA13-4CA9-A8D3-07F3AB9B38F5@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/p7rL9_0-Z7zXyH3MZkO1ymS-5BU Subject: Re: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:40:44 -0000 Hi Russ, Two observations/questions about clause 5.1. > [ASN1-88] International Telephone and Telegraph Consultative=20 > Committee, "Specification of Abstract Syntax Notation One (ASN.1)",=20 > CCITT Recommendation X.208, 1988. How is it possible to cite a specification as normative that no longer exists? > [ASN1-97] International Telecommunications Union, "Abstract Syntax=20 > Notation One (ASN.1): Specification of basic notation", ITU-T=20 > Recommendation X.680, 1997.=20 1. The organization name is "International Telecommunication Union" 2. How is it possible to cite the 1997 version as normative when it has been superseded? Are any of the amendments or corrections included? These seem like significant questions that anyone attempting to implement the RFC would ask. --tony On 2014-04-23 12:21 PM, Russ Housley wrote: > I updated this document to do two things: > > (1) correct an error discovered by Roni Even in his Gen-ART Review. > > (2) add a sentence to the security considerations about id-pe-nsa. > > Russ > ure assignments within that arc. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Wed Apr 23 13:43:45 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CDB1A0651 for ; Wed, 23 Apr 2014 13:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2_IqcsoKoPv for ; Wed, 23 Apr 2014 13:43:41 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id D2E581A064D for ; Wed, 23 Apr 2014 13:43:41 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 31954F2C080; Wed, 23 Apr 2014 16:43:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 6bP5f3lSXhix; Wed, 23 Apr 2014 16:43:05 -0400 (EDT) Received: from 156-193.netmundial.org (unknown [199.91.193.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C63D6F2C07B; Wed, 23 Apr 2014 16:43:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <5357ED02.2070006@yaanatech.com> Date: Wed, 23 Apr 2014 16:42:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1CB7910D-932C-445B-A8BE-2B94ADB3ECAF@vigilsec.com> References: <20140423161753.18398.17304.idtracker@ietfa.amsl.com> <57EE9DB9-BA13-4CA9-A8D3-07F3AB9B38F5@vigilsec.com> <5357ED02.2070006@yaanatech.com> To: tony@yaanatech.com X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/PVcwhnKWGRZ3ixAsBObi_JkvLZo Cc: IETF PKIX Subject: Re: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 20:43:43 -0000 Tony: >> [ASN1-88] International Telephone and Telegraph Consultative = Committee, "Specification of Abstract Syntax Notation One (ASN.1)", = CCITT Recommendation X.208, 1988. >=20 > How is it possible to cite a specification as normative > that no longer exists? Some of the PKIX documents use the 1988 version, and others use the = later versions. Fortunately, these are compatible in their use of = object identifiers, so this does not become an issue here. Of course, = there are other aspects os ASN.1 that are not compatible between the = 1988 version and later versions. >> [ASN1-97] International Telecommunications Union, "Abstract Syntax = Notation One (ASN.1): Specification of basic notation", ITU-T = Recommendation X.680, 1997.=20 >=20 > 1. The organization name is "International Telecommunication Union" > 2. How is it possible to cite the 1997 version as normative when it > has been superseded? Are any of the amendments or corrections > included? >=20 > These seem like significant questions that anyone attempting > to implement the RFC would ask. Please excuse the typo. It will be corrected. Actually, since this document only uses object identifiers, there are = not concerns with the version as explained above. Russ From nobody Wed Apr 23 18:07:10 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65BC1A02BB for ; Wed, 23 Apr 2014 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEX6qVGzFaQx for ; Wed, 23 Apr 2014 18:07:01 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B7F441A02B9 for ; Wed, 23 Apr 2014 18:07:00 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3O16rDZ023206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Apr 2014 03:06:53 +0200 (MEST) In-Reply-To: <1CB7910D-932C-445B-A8BE-2B94ADB3ECAF@vigilsec.com> To: Russ Housley Date: Thu, 24 Apr 2014 03:06:53 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140424010653.061F91ACDD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/ltOv2p_G8rmlbhB8WW4HNoOZeFo Cc: IETF PKIX Subject: Re: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 01:07:06 -0000 Russ Housley wrote: > Tony: > >> [ASN1-88] International Telephone and Telegraph Consultative Committee, >> "Specification of Abstract Syntax Notation One (ASN.1)", >> CCITT Recommendation X.208, 1988. >> >> How is it possible to cite a specification as normative >> that no longer exists? > > Actually, since this document only uses object identifiers, > there are no concerns with the version as explained above. "no longer exists" do not seem to describe the facts adequately. The document X.209, 1988 still exists, you can publicly download it here: http://www.itu.int/rec/T-REC-X.208-198811-W/en And if you desperately want to pay for it, there is an URL on that page suggesting that ITU might be willing to still sell this document to you. "withdrawn" / "superseded" is terminology that is regularly abused by marketing departments to push a specific desire, but does not necessarily match market behaviour, i.e. the perceived nuisance commonly known as the "real world". -Martin From nobody Wed Apr 23 19:07:33 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750321A077A for ; Wed, 23 Apr 2014 19:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJGE7ZowtfCC for ; Wed, 23 Apr 2014 19:07:28 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with SMTP id AAE801A076A for ; Wed, 23 Apr 2014 19:07:28 -0700 (PDT) Received: from [192.168.1.51] (pool-71-171-106-160.clppva.fios.verizon.net [71.171.106.160]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 2633D5802B; Thu, 24 Apr 2014 02:07:37 +0000 (UTC) Message-ID: <535871D8.6020108@yaanatech.com> Date: Wed, 23 Apr 2014 22:07:20 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: mrex@sap.com, Russ Housley References: <20140424010653.061F91ACDD@ld9781.wdf.sap.corp> In-Reply-To: <20140424010653.061F91ACDD@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------060303020901010308010107" Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/ei8jNhtxrwrusENVA__n0Yu_DJs Cc: IETF PKIX Subject: Re: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 02:07:31 -0000 This is a multi-part message in MIME format. --------------060303020901010308010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Well then maybe terms like "normative" shouldn't be used either. :-) On 2014-04-23 9:06 PM, Martin Rex wrote: > "withdrawn" / "superseded" is terminology that is regularly abused > by marketing departments to push a specific desire, but does not > necessarily match market behaviour, i.e. the perceived nuisance > commonly known as the "real world". --=20 ________________________________ ** *Tony Rutkowski* EVP, Industry Standards & Regulatory Affairs tony@yaanatech.com ** *Yaana Technologies LLC * 542 Gibraltar Drive Milpitas CA 95035 USA --------------060303020901010308010107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well then maybe terms like "normative" shouldn't
be used either. :-) 


On 2014-04-23 9:06 PM, Martin Rex wrote:
"withdrawn" / "superseded" is terminology that is re=
gularly abused
by marketing departments to push a specific desire, but does not
necessarily match market behaviour, i.e. the perceived nuisance
commonly known as the "real world".

--

______________= __________________

Tony Rutkowski

EVP, Industry Standards & Regulatory Affairs

tony@yaanatech.com

Yaana Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 USA

--------------060303020901010308010107-- From nobody Wed Apr 23 23:20:36 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A961A079D for ; Wed, 23 Apr 2014 23:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgUiUKoqVZSE for ; Wed, 23 Apr 2014 23:20:31 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 138071A007F for ; Wed, 23 Apr 2014 23:20:30 -0700 (PDT) Received: from ([62.44.134.83]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id KKS37921 for ; Thu, 24 Apr 2014 08:20:21 +0200 From: "Erik Andersen" To: "'IETF PKIX'" References: <1CB7910D-932C-445B-A8BE-2B94ADB3ECAF@vigilsec.com> <20140424010653.061F91ACDD@ld9781.wdf.sap.corp> In-Reply-To: <20140424010653.061F91ACDD@ld9781.wdf.sap.corp> Date: Thu, 24 Apr 2014 08:20:13 +0200 Message-ID: <001001cf5f85$45b93b10$d12bb130$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIQbSJVdlgWJgunhcVYL3atMNHZZpqeL0NQ Content-Language: da Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/8pG80zRnNhQY9F6C--8TcW5dCpg Subject: Re: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:20:33 -0000 The 2002 edition of ASN.1 is also freely available, so money cannot be the excuse for PKIX to produce back level specifications (http://www.itu.int/rec/T-REC-X.680-200207-S/en). Erik -----Original Message----- From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Martin Rex Sent: Thursday, April 24, 2014 3:07 AM To: Russ Housley Cc: IETF PKIX Subject: Re: [pkix] Fwd: New Version Notification for draft-housley-pkix-oids-03.txt Russ Housley wrote: > Tony: > >> [ASN1-88] International Telephone and Telegraph Consultative >> Committee, "Specification of Abstract Syntax Notation One (ASN.1)", >> CCITT Recommendation X.208, 1988. >> >> How is it possible to cite a specification as normative that no >> longer exists? > > Actually, since this document only uses object identifiers, there are > no concerns with the version as explained above. "no longer exists" do not seem to describe the facts adequately. The document X.209, 1988 still exists, you can publicly download it here: http://www.itu.int/rec/T-REC-X.208-198811-W/en And if you desperately want to pay for it, there is an URL on that page suggesting that ITU might be willing to still sell this document to you. "withdrawn" / "superseded" is terminology that is regularly abused by marketing departments to push a specific desire, but does not necessarily match market behaviour, i.e. the perceived nuisance commonly known as the "real world". -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Thu Apr 24 09:23:59 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2821A037A for ; Thu, 24 Apr 2014 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FIDOETmBuYv; Thu, 24 Apr 2014 09:23:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8D61A0395; Thu, 24 Apr 2014 09:23:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: housley@vigilsec.com, draft-housley-pkix-oids@tools.ietf.org, pkix@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424162350.9490.20028.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 09:23:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/G645EVqAEpyMOme3X7VZmEymaH0 Subject: [pkix] ID Tracker State Update Notice: X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:23:57 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-housley-pkix-oids/ From nobody Thu Apr 24 09:55:44 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D261A02B5 for ; Thu, 24 Apr 2014 09:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5DyxPK4av9a for ; Thu, 24 Apr 2014 09:55:39 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id A2D1C1A02AD for ; Thu, 24 Apr 2014 09:55:39 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7F43C1A009F for ; Thu, 24 Apr 2014 18:55:32 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n9LFz_iaoz-T for ; Thu, 24 Apr 2014 18:55:23 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id EEBA81A009E for ; Thu, 24 Apr 2014 18:55:23 +0200 (CEST) Received: from [10.53.40.204] (port=55022 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WdMvj-0006Ym-9b for ; Thu, 24 Apr 2014 18:55:23 +0200 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 24 Apr 2014 18:55:23 +0200 Message-ID: <535941FA.60103@secunet.com> Date: Thu, 24 Apr 2014 18:55:22 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: References: <000901cf557d$510aa9c0$f31ffd40$@x500.eu> <5347DB6A.6020609@free.fr> <001801cf5581$4841aec0$d8c50c40$@x500.eu> <5348011A.6010902@free.fr>, <53503D9A.1060101@nist.gov> <20825998BCB8D84C983674C159E25E753D4C1E65@mbs6.app.corp.cht.com.tw>, <5350E92B.9000106@free.fr>, <20825998BCB8D84C983674C159E25E753D4C290F@mbs6.app.corp.cht.com.tw> <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw> In-Reply-To: <20825998BCB8D84C983674C159E25E753D4C2C41@mbs6.app.corp.cht.com.tw> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/xawrF9svlDnK2LeJEOaA__2GDz4 Subject: Re: [pkix] ACs an OCSP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:55:42 -0000 > However, since here we are in a WG concerning Internet Standard, folks might be interested to clarify whether current > RFCs defined by this WG can provide a standard way to check AC revocation status over OCSP. IMHO it would have been beneficial to allow (maybe under certain circumstances) trust in OCSP signer certificates issued by the (superordinated) CA that issued the CA certificate used to issue the validated certificate. In this case a CA could have obtained certificates for both certificate signing and OCSP signing from the same issuer. And in the case of a CA key compromise, the OCSP responses for the certificates issued by that CA could still be trusted (unless the higher level CA has been compromised as well). -- Johannes From nobody Wed Apr 30 07:35:02 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5AA1A08AC for ; Wed, 30 Apr 2014 07:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hno_4IpWnvow for ; Wed, 30 Apr 2014 07:35:00 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.164.21]) by ietfa.amsl.com (Postfix) with ESMTP id 072391A6F6D for ; Wed, 30 Apr 2014 07:35:00 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 4C73CFE303061; Wed, 30 Apr 2014 09:34:58 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 2B67BFE2E125B for ; Wed, 30 Apr 2014 09:32:04 -0500 (CDT) Received: from [96.231.225.192] (port=62397 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WfVXY-0007Vs-3a for pkix@ietf.org; Wed, 30 Apr 2014 09:31:16 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Apr 2014 10:31:13 -0400 References: <20140430142954.2368.21276.idtracker@ietfa.amsl.com> To: IETF PKIX Message-Id: <6E301B05-5D8E-46BB-B323-792EBE1D4C22@ieca.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WfVXY-0007Vs-3a X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:62397 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/VLq_-88XBnAoyXA0HH7AGeSGbIo Subject: [pkix] Fwd: I-D Action: draft-turner-est-extensions-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:35:01 -0000 Some on this list might find this of interest. spt Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-turner-est-extensions-02.txt > Date: April 30, 2014 at 10:29:54 EDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : EST Extensions > Author : Sean Turner > Filename : draft-turner-est-extensions-02.txt > Pages : 41 > Date : 2014-04-30 >=20 > Abstract: > The EST (Enrollment over Secure Transport) protocol defined a Well- > Known URI (Uniform Resource Identifier): /.well-known/est. EST also > defined several path components that clients use for PKI (Public Key > Infrastructure) services, namely certificate enrollment (e.g., > /simpleenroll). In some sense, the services provided by the path > components can be thought of as PKI management-related packages. > There are additional PKI-related packages a client might need as = well > as other security-related packages, such as firmware, trust anchors, > and symmetric, asymmetric, and encrypted keys. This document also > specifies the PAL (Package Availability List), which is an XML > (Extensible Markup Language) file that clients use to retrieve > packages available and authorized for them. This document extends > the EST server path components to provide these additional services. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-turner-est-extensions/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-turner-est-extensions-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-turner-est-extensions-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Apr 30 08:56:59 2014 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4659F1A6FF4 for ; Wed, 30 Apr 2014 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC84goKCk5Tn for ; Wed, 30 Apr 2014 08:56:57 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE641A6FE5 for ; Wed, 30 Apr 2014 08:56:57 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u57so1913755wes.27 for ; Wed, 30 Apr 2014 08:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AMF5ktLBLDHz5kEFivSbqXxId7IiDDCsiXVnHyw0NMY=; b=OZwgWdxIchfAIeVoTwJL8N4ipzFdrJG34kekmDPnR1Qm3iqTW+SN58Eoo/bRrAaBu0 NTr8jVFhWXFv67R7uFK3eJ41FwY+3vexhm3QihR3xGZXwjU8ac/sVBqMv10WNk15/2P3 b9kjO4SK2nfnh/q8rdk8Ri2ZgA+a5aYGtybdMeFTfiPBUR644HiFO+Ean5wrhmA+6T6C TOBtOvUEAj16URqCo+l7YHni2kAPHcrHKHtz2n4ZbvibQ2R7A5tjh4hNvUqj2cw9Z7UY fevOKbTZIzsZC1Qr36MoKUIbVP/ONLHrX/QcfhmAUJl3I/ARcfYtRE+3r3DCcJRaqvRX d7Xg== X-Received: by 10.180.211.239 with SMTP id nf15mr4338500wic.9.1398873415324; Wed, 30 Apr 2014 08:56:55 -0700 (PDT) Received: from [192.168.1.99] (48.248.130.77.rev.sfr.net. [77.130.248.48]) by mx.google.com with ESMTPSA id b2sm4438846wiz.15.2014.04.30.08.56.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 08:56:54 -0700 (PDT) Message-ID: <53611D42.10707@gmail.com> Date: Wed, 30 Apr 2014 17:56:50 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Sean Turner , IETF PKIX References: <20140430142954.2368.21276.idtracker@ietfa.amsl.com> <6E301B05-5D8E-46BB-B323-792EBE1D4C22@ieca.com> In-Reply-To: <6E301B05-5D8E-46BB-B323-792EBE1D4C22@ieca.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/wYz9fNxTr5uhDKDr5WvTOz5OPeA Subject: Re: [pkix] Fwd: I-D Action: draft-turner-est-extensions-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:56:59 -0000 On 2014-04-30 16:31, Sean Turner wrote: > Some on this list might find this of interest. I never understood the use-case for EST and this addition didn't made it clearer. I guess this is something ordered by the US government? Anders > > spt > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-turner-est-extensions-02.txt >> Date: April 30, 2014 at 10:29:54 EDT >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : EST Extensions >> Author : Sean Turner >> Filename : draft-turner-est-extensions-02.txt >> Pages : 41 >> Date : 2014-04-30 >> >> Abstract: >> The EST (Enrollment over Secure Transport) protocol defined a Well- >> Known URI (Uniform Resource Identifier): /.well-known/est. EST also >> defined several path components that clients use for PKI (Public Key >> Infrastructure) services, namely certificate enrollment (e.g., >> /simpleenroll). In some sense, the services provided by the path >> components can be thought of as PKI management-related packages. >> There are additional PKI-related packages a client might need as well >> as other security-related packages, such as firmware, trust anchors, >> and symmetric, asymmetric, and encrypted keys. This document also >> specifies the PAL (Package Availability List), which is an XML >> (Extensible Markup Language) file that clients use to retrieve >> packages available and authorized for them. This document extends >> the EST server path components to provide these additional services. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-turner-est-extensions/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-turner-est-extensions-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-turner-est-extensions-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >