From denis.pinkas@bull.net Fri Jun 1 00:24:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1F321F861D for ; Fri, 1 Jun 2012 00:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txBWCFg+SVks for ; Fri, 1 Jun 2012 00:24:17 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id A173821F861C for ; Fri, 1 Jun 2012 00:24:16 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id D0960120036; Fri, 1 Jun 2012 09:24:14 +0200 (CEST) In-Reply-To: <8762bbaa15.fsf@windlord.stanford.edu> References: <4FC6AEDA.4010709@cs.tcd.ie> <8762bbaa15.fsf@windlord.stanford.edu> To: Russ Allbery , hotz@jpl.nasa.gov MIME-Version: 1.0 X-KeepSent: EBA66BA3:DC95987A-C1257A10:00278E13; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 1 Jun 2012 09:24:13 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 01/06/2012 09:24:14, Serialize complete at 01/06/2012 09:24:14 Content-Type: multipart/alternative; boundary="=_alternative 00287E8CC1257A10_=" Cc: pkix , Jim Schaad Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 07:24:18 -0000 Message en plusieurs parties au format MIME --=_alternative 00287E8CC1257A10_= Content-Type: text/plain; charset="US-ASCII" First of all, thank you for both of you for your fast response. I am not arguing there is an RFC 5742 conflict with this document. Since you said that is an attempt to document an existing deployed protocol, we cannot change it. Since you said that designing a better protocol is an expected follow-on work, I raise the question to both the editors and the WG chairs whether the document should be on the experimental track rather than on the informational track. Clearly, I believe that only changes to the security consideration sections should be made, keeping in mind that confidentiality an integrity protection can be done at lower layers. This is what the security considerations section should recommend. Finally, I believe an errata on RFC 4211 should be prepared, but this is a separate concern with Jim. Denis De : Russ Allbery A : denis.pinkas@bull.net Cc : hotz@jpl.nasa.gov, Jim Schaad , pkix Date : 01/06/2012 07:20 Objet : Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 denis.pinkas@bull.net writes: > I skimmed through the document and read the following two sentences: > The public key in the request is sent in the clear, and without any > guarantees that the requestor actually possesses the corresponding > private key. > [RFC4211], Appendix C contains a more detailed discussion of why > proof-of-possession is important. > I have concerns with both sentences. > [RFC4211] is incorrect and this has security implications on the > proposed protocol. Hi Denis, As Henry has mentioned, we have the limitation with this particular document that we're attempting to document an existing, deployed protocol sufficiently that interoperable implementations can be created. This protocol is deficient in multiple ways, and designing a better protocol is expected follow-on work. Changing something fundamental, such as requiring confidentiality in this protocol exchange, would defeat the point of the current work. Therefore, I think that any remedy here should be limited to clearly documenting the issue in the Security Considerations section rather than changing the protocol. If I'm understanding your message properly, you're saying that there is a partial defense against the lack of proof-of-possession by adding confidentiality protection to the exchange. I'm not sure in this context whether this really changes the security analysis of this protocol, given that no confidentiality is used. But if I'm missing something, could you suggest something that we could add to Security Considerations? -- Russ Allbery (rra@stanford.edu) --=_alternative 00287E8CC1257A10_= Content-Type: text/html; charset="US-ASCII" First of all, thank you for both of you for your fast response.

I am not arguing there is an RFC 5742 conflict with this document.

Since you said that is an attempt to document an existing deployed protocol, we cannot change it.

Since you said that designing a better protocol is an expected follow-on work, I raise the question to both the editors and the WG chairs
whether the document should be on the experimental track rather than on the informational track.

Clearly, I believe that only changes to the security consideration sections should be made, keeping in mind that
confidentiality an integrity protection can be done at lower layers. This is what the security considerations section should recommend.

Finally, I believe an errata on RFC 4211 should be prepared, but this is a separate concern with Jim.

Denis



De :        Russ Allbery <rra@stanford.edu>
A :        denis.pinkas@bull.net
Cc :        hotz@jpl.nasa.gov, Jim Schaad <ietf@augustcellars.com>, pkix <pkix@ietf.org>
Date :        01/06/2012 07:20
Objet :        Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211



denis.pinkas@bull.net writes:

> I skimmed through the document and read the following two sentences:

>    The public key in the request is sent in the clear, and without any
>    guarantees that the requestor actually possesses the corresponding
>    private key.

>    [RFC4211], Appendix C contains a more detailed discussion of why
>    proof-of-possession is important.

> I have concerns with both sentences.

> [RFC4211] is incorrect and this has security implications on the
> proposed protocol.

Hi Denis,

As Henry has mentioned, we have the limitation with this particular
document that we're attempting to document an existing, deployed protocol
sufficiently that interoperable implementations can be created.  This
protocol is deficient in multiple ways, and designing a better protocol is
expected follow-on work.  Changing something fundamental, such as
requiring confidentiality in this protocol exchange, would defeat the
point of the current work.

Therefore, I think that any remedy here should be limited to clearly
documenting the issue in the Security Considerations section rather than
changing the protocol.

If I'm understanding your message properly, you're saying that there is a
partial defense against the lack of proof-of-possession by adding
confidentiality protection to the exchange.  I'm not sure in this context
whether this really changes the security analysis of this protocol, given
that no confidentiality is used.  But if I'm missing something, could you
suggest something that we could add to Security Considerations?

--
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
--=_alternative 00287E8CC1257A10_=-- From denis.pinkas@bull.net Fri Jun 1 00:48:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4950121F862B for ; Fri, 1 Jun 2012 00:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtfaqnDe5JNf for ; Fri, 1 Jun 2012 00:48:52 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id AF86621F8627 for ; Fri, 1 Jun 2012 00:48:51 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 1284E120045; Fri, 1 Jun 2012 09:48:51 +0200 (CEST) In-Reply-To: <4FC7E512.3000801@comodo.com> References: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> <4FC7E512.3000801@comodo.com> To: Rob Stradling MIME-Version: 1.0 X-KeepSent: 53BFA485:69DC6594-C1257A10:0029E605; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 1 Jun 2012 09:48:50 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 01/06/2012 09:48:50, Serialize complete at 01/06/2012 09:48:50 Content-Type: multipart/alternative; boundary="=_alternative 002AD124C1257A10_=" Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 07:48:53 -0000 Message en plusieurs parties au format MIME --=_alternative 002AD124C1257A10_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Rob, I do not "buy" your argumentation, since it is based on RFC 2459 which is=20 now obsolete and had two successors. Also, your argumentation is defeated, simply because RFC 2459 was issued=20 before RFC 2560, which means=20 before OCSP ever existed. As I already said on the list , at the time RFC 2560 was issued, we should = have asked to ITU-T to add a OCSPsign key usage bit. Nobody raised the point at the proper time. It seems too late now. So=20 asserting instead the DS bit is not the perfect solution,=20 but it is the most acceptable. Denis=20 De : Rob Stradling A : mrex@sap.com Cc : "pkix@ietf.org" Date : 31/05/2012 23:39 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits Envoy=E9 par : pkix-bounces@ietf.org On 31/05/12 16:59, Martin Rex wrote: > Rob Stradling wrote: >> >> Are you saying that trying to "fix" the standards is not really an=20 option? >> >> What security hole would be introduced by once again allowing the >> "crlSign" bit to authorize the CA certificate as an Integrated=20 Responder? > > This is =5FNOT=5F a defect of rfc2560, it was a conscious design decision, > and a careful implementor should have seen this. RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign=20 bit is asserted when the subject public key is used for verifying a=20 signature on revocation information (e.g., a CRL)." So if there was "a conscious design decision" by the RFC2560 authors=20 regarding which Key Usage bits should be set in the Integrated Responder=20 case, then surely that decision was in agreement with what I am asking=20 for and in disagreement with the altered text in RFCs 3280 and 5280! > So "fixing" does not exist as an option only changing the behaviour > in a successor OCSP spec. But should still account for implementations > based on rfc2560 alone. And what about accounting for implementations based on RFC2459 alone? > What is more confusing to me is that you're PKI software did not > error on your attempt to sign OCSP responses without the > DigitalSignature bit in your CA cert. When sensibly implemented, Our PKI software was written by me, and until this week I hadn't noticed=20 that RFC3280/5280 changed the rules on which Key Usage bit means what.=20 Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice=20 sooner. Call me a careless implementor if you like. >a signature creation function should perform a number of plausibility > checks on signature creation (including KeyUsage and Validity), > because it does not make sense (other than in very limited debug > situations) to create digital signatures that receipients will > very probably fail verifying. Let's look at this from another angle: What would happen today if a CA decides to implement an=20 RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs?=20 If they follow RFC5280's guidance, they will set keyCertSign and=20 digitalSignature (but NOT cRLSign) in the CA Certificate(s). Then, what would happen when an RFC2459-compliant client attempts to=20 perform an OCSP check on an end-entity certificate from this PKI? If=20 the client enforces the RFC2459 definitions of the Key Usage bits, it=20 would reject the OCSP Response because the CA Certificate does not have=20 the cRLSign bit set!! > -Martin > --=20 Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and=20 intended solely for the use of the individual or entity to whom they are=20 addressed. If you have received this email in error please notify the=20 sender by replying to the e-mail containing this attachment. Replies to=20 this email may be monitored by COMODO for operational or business=20 reasons. Whilst every endeavour is taken to ensure that e-mails are free=20 from viruses, no liability can be accepted and the recipient is=20 requested to use their own virus checking software. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 002AD124C1257A10_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Rob,

I do not "buy" your argumentati= on, since it is based on RFC 2459 which is now obsolete and had two successors.=
Also, your argumentation is defeated, sim= ply because RFC 2459 was issued before RFC 2560, which means
before OCSP ever existed.

As I already said on the list , at t= he time RFC 2560 was issued, we should have asked to ITU-T to add a OCSPsign key usage bit.
Nobody raised the point at the proper time. It seems too late now. So asserting instead the DS bit is not the perfect solution,
but it is the most acceptable.

Denis




De :     &= nbsp;  Rob Stradling <rob.strad= ling@comodo.com>
A :     &n= bsp;  mrex@sap.com
Cc :   &nb= sp;    "pkix@ietf.org&= quot; <pkix@ietf.org>
Date :    =    31/05/2012 23:39
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



On 31/05/12 16:59, Martin Rex wrote:
> Rob Stradling wrote:
>>
>> Are you saying that trying to "fix" the standards is not really an option?
>>
>> What security hole would be introduced by once again allowing the
>> "crlSign" bit to authorize the CA certificate as an Integrated Responder?
>
> This is =5FNOT=5F a defect of rfc2560, it was a conscious design decis= ion,
> and a careful implementor should have seen this.

RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSi= gn
bit is asserted when the subject public key is used for verifying a
signature on revocation information (e.g., a CRL)."

So if there was "a conscious design decision" by the RFC2560 authors
regarding which Key Usage bits should be set in the Integrated Responder
case, then surely that decision was in agreement with what I am asking
for and in disagreement with the altered text in RFCs 3280 and 5280!

> So "fixing" does not exist as an option only changing the behaviour
> in a successor OCSP spec.  But should still account for implement= ations
> based on rfc2560 alone.

And what about accounting for implementations based on RFC2459 alone?

> What is more confusing to me is that you're PKI software did not
> error on your attempt to sign OCSP responses without the
> DigitalSignature bit in your CA cert.   When sensibly implemented= ,

Our PKI software was written by me, and until this week I hadn't noticed
that RFC3280/5280 changed the rules on which Key Usage bit means what.
Yes, I know RFC3280 was published 10 years ago.  Sorry I didn't notice
sooner.  Call me a careless implementor if you like.

>a signature creation function should perform a number of plausibility > checks on signature creation (including KeyUsage and Validity),
> because it does not make sense (other than in very limited debug
> situations) to create digital signatures that receipients will
> very probably fail verifying.

Let's look at this from another angle:
What would happen today if a CA decides to implement an
RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs?
 If they follow RFC5280's guidance, they will set keyCertSign and
digitalSignature (but NOT cRLSign) in the CA Certificate(s).
Then, what would happen when an RFC2459-compliant client attempts to
perform an OCSP check on an end-entity certificate from this PKI?  If
the client enforces the RFC2459 definitions of the Key Usage bits, it
would reject the OCSP Response because the CA Certificate does not have
the cRLSign bit set!!

> -Martin
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 002AD124C1257A10_=-- From hotz@jpl.nasa.gov Fri Jun 1 01:17:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B3021F862B for ; Fri, 1 Jun 2012 01:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJi6qSwE8olf for ; Fri, 1 Jun 2012 01:17:31 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id C810B21F861F for ; Fri, 1 Jun 2012 01:17:30 -0700 (PDT) Received: from [192.168.2.107] (adsl-99-146-13-117.dsl.lsan03.sbcglobal.net [99.146.13.117]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q518H4wX012197 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 1 Jun 2012 01:17:04 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Fri, 1 Jun 2012 01:17:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A52FBC3-0C84-405B-804E-ECE01C3DE966@jpl.nasa.gov> References: <4FC6AEDA.4010709@cs.tcd.ie> <8762bbaa15.fsf@windlord.stanford.edu> To: X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-JPL-Spam-Score': 80% Cc: pkix , Russ Allbery , Jim Schaad Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 08:17:34 -0000 On Jun 1, 2012, at 12:24 AM, wrote: > First of all, thank you for both of you for your fast response.=20 No prob. > I am not arguing there is an RFC 5742 conflict with this document.=20 OK. Thanks. > Since you said that is an attempt to document an existing deployed = protocol, we cannot change it.=20 >=20 > Since you said that designing a better protocol is an expected = follow-on work, I raise the question to both the editors and the WG = chairs whether the document should be on the experimental track rather = than on the informational track.=20 The question has come up before, at least generically. (With Steve Kent = IIRC.) I don't think it should be standards track because we want to = fix it. I don't think it's actually experimental because it's somewhat = widely deployed. I don't think it's historic because it's currently in = use and we don't have a replacement designed yet. I do think it's = informational because, well, the document is providing useful = information about a real internet protocol. > Clearly, I believe that only changes to the security consideration = sections should be made, keeping in mind that confidentiality an = integrity protection can be done at lower layers. This is what the = security considerations section should recommend.=20 As I said in other email, adding confidentiality will probably be done = in a future, incompatible version. Integrity protection is already = provided (though without algorithm agility which will also be added in a = future, incompatible version). The existing deployments are over bare = UDP. > Finally, I believe an errata on RFC 4211 should be prepared, but this = is a separate concern with Jim.=20 >=20 > Denis=20 >=20 >=20 >=20 > De : Russ Allbery =20 > A : denis.pinkas@bull.net=20 > Cc : hotz@jpl.nasa.gov, Jim Schaad , = pkix =20 > Date : 01/06/2012 07:20=20 > Objet : Re: [pkix] RFC 5742 review of draft-hotz-kx509 and = about RFC 4211=20 >=20 >=20 >=20 > denis.pinkas@bull.net writes: >=20 > > I skimmed through the document and read the following two sentences: >=20 > > The public key in the request is sent in the clear, and without = any > > guarantees that the requestor actually possesses the = corresponding > > private key. >=20 > > [RFC4211], Appendix C contains a more detailed discussion of why=20= > > proof-of-possession is important. >=20 > > I have concerns with both sentences. >=20 > > [RFC4211] is incorrect and this has security implications on the > > proposed protocol. >=20 > Hi Denis, >=20 > As Henry has mentioned, we have the limitation with this particular > document that we're attempting to document an existing, deployed = protocol > sufficiently that interoperable implementations can be created. This > protocol is deficient in multiple ways, and designing a better = protocol is > expected follow-on work. Changing something fundamental, such as > requiring confidentiality in this protocol exchange, would defeat the > point of the current work. >=20 > Therefore, I think that any remedy here should be limited to clearly > documenting the issue in the Security Considerations section rather = than > changing the protocol. >=20 > If I'm understanding your message properly, you're saying that there = is a > partial defense against the lack of proof-of-possession by adding > confidentiality protection to the exchange. I'm not sure in this = context > whether this really changes the security analysis of this protocol, = given > that no confidentiality is used. But if I'm missing something, could = you > suggest something that we could add to Security Considerations? >=20 > --=20 > Russ Allbery (rra@stanford.edu) = >=20 ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From era@x500.eu Fri Jun 1 01:55:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE0421F85C9 for ; Fri, 1 Jun 2012 01:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8-x02AsyeBK for ; Fri, 1 Jun 2012 01:55:26 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id D872B21F85C5 for ; Fri, 1 Jun 2012 01:55:25 -0700 (PDT) Received: from Morten ([94.191.226.29]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id LOE01123; Fri, 01 Jun 2012 10:55:23 +0200 From: "Erik Andersen" To: References: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> <4FC7E512.3000801@comodo.com> In-Reply-To: Date: Fri, 1 Jun 2012 10:55:19 +0200 Message-ID: <003e01cd3fd4$498ce700$dca6b500$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01CD3FE5.0D15B700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0/ywWwtSU/tqNfTE2aq3CGIvBzxgAB9+/g Content-Language: da Cc: pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 08:55:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003F_01CD3FE5.0D15B700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not arguing for a OCSPsign bit. However, if it is seen useful, the = time is now if we want it to be in the next edition of X.509, which is almost finalised. Otherwise, it would be delayed probably another four years. =20 Implementers will have to judge whether introducing such a bit at this = late state will cause interworking problems. =20 Erik=20 =20 Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af denis.pinkas@bull.net Sendt: 1. juni 2012 09:49 Til: Rob Stradling Cc: pkix@ietf.org Emne: Re: [pkix] Integrated OCSP Responders / Key Usage bits =20 Rob,=20 I do not "buy" your argumentation, since it is based on RFC 2459 which = is now obsolete and had two successors.=20 Also, your argumentation is defeated, simply because RFC 2459 was issued before RFC 2560, which means=20 before OCSP ever existed.=20 As I already said on the list , at the time RFC 2560 was issued, we = should have asked to ITU-T to add a OCSPsign key usage bit.=20 Nobody raised the point at the proper time. It seems too late now. So asserting instead the DS bit is not the perfect solution,=20 but it is the most acceptable.=20 Denis=20 De : Rob Stradling =20 A : mrex@sap.com=20 Cc : "pkix@ietf.org" =20 Date : 31/05/2012 23:39=20 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20 Envoy=E9 par : pkix-bounces@ietf.org=20 _____ =20 On 31/05/12 16:59, Martin Rex wrote: > Rob Stradling wrote: >> >> Are you saying that trying to "fix" the standards is not really an option? >> >> What security hole would be introduced by once again allowing the >> "crlSign" bit to authorize the CA certificate as an Integrated = Responder? > > This is _NOT_ a defect of rfc2560, it was a conscious design decision, > and a careful implementor should have seen this. RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign = bit is asserted when the subject public key is used for verifying a=20 signature on revocation information (e.g., a CRL)." So if there was "a conscious design decision" by the RFC2560 authors=20 regarding which Key Usage bits should be set in the Integrated Responder = case, then surely that decision was in agreement with what I am asking=20 for and in disagreement with the altered text in RFCs 3280 and 5280! > So "fixing" does not exist as an option only changing the behaviour > in a successor OCSP spec. But should still account for = implementations > based on rfc2560 alone. And what about accounting for implementations based on RFC2459 alone? > What is more confusing to me is that you're PKI software did not > error on your attempt to sign OCSP responses without the > DigitalSignature bit in your CA cert. When sensibly implemented, Our PKI software was written by me, and until this week I hadn't noticed = that RFC3280/5280 changed the rules on which Key Usage bit means what.=20 Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice=20 sooner. Call me a careless implementor if you like. >a signature creation function should perform a number of plausibility > checks on signature creation (including KeyUsage and Validity), > because it does not make sense (other than in very limited debug > situations) to create digital signatures that receipients will > very probably fail verifying. Let's look at this from another angle: What would happen today if a CA decides to implement an=20 RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs?=20 If they follow RFC5280's guidance, they will set keyCertSign and=20 digitalSignature (but NOT cRLSign) in the CA Certificate(s). Then, what would happen when an RFC2459-compliant client attempts to=20 perform an OCSP check on an end-entity certificate from this PKI? If=20 the client enforces the RFC2459 definitions of the Key Usage bits, it=20 would reject the OCSP Response because the CA Certificate does not have=20 the cRLSign bit set!! > -Martin > --=20 Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and=20 intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the=20 sender by replying to the e-mail containing this attachment. Replies to=20 this email may be monitored by COMODO for operational or business=20 reasons. Whilst every endeavour is taken to ensure that e-mails are free = from viruses, no liability can be accepted and the recipient is=20 requested to use their own virus checking software. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_003F_01CD3FE5.0D15B700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am not arguing for a OCSPsign bit. However, if it is seen useful, = the time is now if we want it to be in the next edition of X.509, which = is almost finalised. Otherwise, it would be delayed probably another = four years.

 

Implementers will have to judge whether introducing such a bit at = this late state will cause interworking = problems.

 

Erik

 

Fra:<= /b> = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = denis.pinkas@bull.net
Sendt: 1. juni 2012 = 09:49
Til: Rob Stradling
Cc: = pkix@ietf.org
Emne: Re: [pkix] Integrated OCSP Responders / = Key Usage bits

 

Rob, =

I do not = "buy" your argumentation, since it is based on RFC 2459 which = is now obsolete and had two successors.
Also, your = argumentation is defeated, simply because RFC 2459 was issued before RFC = 2560, which means
before OCSP ever existed.

As I already = said on the list , at the time RFC 2560 was issued, we should have asked = to ITU-T to add a OCSPsign key usage bit.
Nobody = raised the point at the proper time. It seems too late now. So asserting = instead the DS bit is not the perfect solution,
but it is the most = acceptable.

Denis =




= De :        Rob Stradling = <rob.stradling@comodo.com>=
= A :        mrex@sap.com
= Cc :        "pkix@ietf.org" <pkix@ietf.org>
= Date :        31/05/2012 = 23:39
= Objet :        Re: [pkix] = Integrated OCSP Responders / Key Usage bits
= Envoy=E9 par :        pkix-bounces@ietf.org =




On 31/05/12 16:59, Martin Rex = wrote:
> Rob Stradling = wrote:
>>
>> Are you saying that = trying to "fix" the standards is not really an = option?
>>
>> What security hole = would be introduced by once again allowing the
>> = "crlSign" bit to authorize the CA certificate as an Integrated = Responder?
>
> This is _NOT_ a defect of = rfc2560, it was a conscious design decision,
> and a = careful implementor should have seen this.

RFC2560 cites = RFC2459 as a reference, and RFC2459 says that "The cRLSign =
bit is asserted when the subject public key is used for = verifying a
signature on revocation information (e.g., a = CRL)."

So if there was "a conscious design = decision" by the RFC2560 authors
regarding which Key = Usage bits should be set in the Integrated Responder
case, = then surely that decision was in agreement with what I am asking =
for and in disagreement with the altered text in RFCs 3280 = and 5280!

> So "fixing" does not exist as = an option only changing the behaviour
> in a successor = OCSP spec.  But should still account for = implementations
> based on rfc2560 = alone.

And what about accounting for implementations = based on RFC2459 alone?

> What is more confusing to = me is that you're PKI software did not
> error on your = attempt to sign OCSP responses without the
> = DigitalSignature bit in your CA cert.   When sensibly = implemented,

Our PKI software was written by me, and = until this week I hadn't noticed
that RFC3280/5280 changed = the rules on which Key Usage bit means what.
Yes, I know = RFC3280 was published 10 years ago.  Sorry I didn't notice =
sooner.  Call me a careless implementor if you = like.

>a signature creation function should perform a = number of plausibility
> checks on signature creation = (including KeyUsage and Validity),
> because it does not = make sense (other than in very limited debug
> = situations) to create digital signatures that receipients = will
> very probably fail = verifying.

Let's look at this from another = angle:
What would happen today if a CA decides to implement = an
RFC5280-compliant PKI that uses = Integrated-Responder-OCSP but not CRLs?
 If they = follow RFC5280's guidance, they will set keyCertSign and =
digitalSignature (but NOT cRLSign) in the CA = Certificate(s).
Then, what would happen when an = RFC2459-compliant client attempts to
perform an OCSP check = on an end-entity certificate from this PKI?  If
the = client enforces the RFC2459 definitions of the Key Usage bits, it =
would reject the OCSP Response because the CA Certificate = does not have
the cRLSign bit set!!

> = -Martin
>

--
Rob = Stradling
Senior Research & Development = Scientist
COMODO - Creating Trust Online
Office = Tel: +44.(0)1274.730505
Office Fax: = +44.(0)1274.730909
www.comodo.com

COMODO = CA Limited, Registered in England No. 04058690
Registered = Office:
  3rd Floor, 26 Office Village, Exchange = Quay,
  Trafford Road, Salford, Manchester M5 = 3EQ

This e-mail and any files transmitted with it are = confidential and
intended solely for the use of the = individual or entity to whom they are
addressed.  If = you have received this email in error please notify the =
sender by replying to the e-mail containing this = attachment. Replies to
this email may be monitored by = COMODO for operational or business
reasons. Whilst every = endeavour is taken to ensure that e-mails are free
from = viruses, no liability can be accepted and the recipient is =
requested to use their own virus checking = software.
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_003F_01CD3FE5.0D15B700-- From mrex@sap.com Fri Jun 1 02:50:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B8B21F8599 for ; Fri, 1 Jun 2012 02:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_OEM_SOFT_IS=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6qtjlb2a+6a for ; Fri, 1 Jun 2012 02:50:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDF521F8595 for ; Fri, 1 Jun 2012 02:50:25 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q519oEgf015345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 11:50:19 +0200 (MEST) In-Reply-To: <4FC7E512.3000801@comodo.com> To: Rob Stradling Date: Fri, 1 Jun 2012 11:50:14 +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: <20120601095014.3FD7A1A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 09:50:39 -0000 Rob Stradling wrote: > > RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign > bit is asserted when the subject public key is used for verifying a > signature on revocation information (e.g., a CRL)." Hmmmm. I think you have a point here. This definition still applies to rfc3280 and rfc5280, actually: http://tools.ietf.org/html/rfc3280#page-29 The cRLSign bit is asserted when the subject public key is used for verifying a signature on certificate revocation list (e.g., a CRL, delta CRL, or an ARL). This bit MUST be asserted in certificates that are used to verify signatures on CRLs. http://tools.ietf.org/html/rfc5280#page-31 The cRLSign bit is asserted when the subject public key is used for verifying signatures on certificate revocation lists (e.g., CRLs, delta CRLs, or ARLs). Although 2459/3280/5280 are "profiles of X.509", it seems sensible to have it apply to technologies that were born/defined in the IETF and not part of X.509 itself. > > > What is more confusing to me is that you're PKI software did not > > error on your attempt to sign OCSP responses without the > > DigitalSignature bit in your CA cert. When sensibly implemented, > > Our PKI software was written by me, and until this week I hadn't noticed > that RFC3280/5280 changed the rules on which Key Usage bit means what. > Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice > sooner. Call me a careless implementor if you like. I'm sorry, I misexplained myself. In order to make something enforcable on the RP, it first of all will have to be enforced on the component that creates that structure/element (=applies the signature). Our OEM PKI software originally refused to sign a PKCS#10 request (request for renewal) when the current certificate was already expired, and I had to employ a special API feature (do not check Validity when signing) in order to obtain the signature. When writing PKI software, it would not be sensible to add a check to the RP part of the software prior to ensuring that the signature creation part enforced that feature to be correct. > > Let's look at this from another angle: > What would happen today if a CA decides to implement an > RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? This is actually something that I consider a defect in rfc5280. Support of OCSP is purely optional (even less that MAY), so support of CRLs being optional would imply that support of revocation is optional -- which might be the reason why nobody hard-fails... http://tools.ietf.org/html/rfc3280#page-49 Last paragraph of Section 5.0 Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. Conforming applications are NOT REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA. -Martin From rob.stradling@comodo.com Fri Jun 1 04:21:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BE421F859B for ; Fri, 1 Jun 2012 04:21:09 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ6K0EcjXPRL for ; Fri, 1 Jun 2012 04:21:08 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6019C21F8646 for ; Fri, 1 Jun 2012 04:21:07 -0700 (PDT) Received: (qmail 22083 invoked from network); 1 Jun 2012 11:21:06 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Jun 2012 11:21:06 -0000 Received: (qmail 27802 invoked by uid 1000); 1 Jun 2012 11:21:05 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 01 Jun 2012 12:21:05 +0100 Message-ID: <4FC8A5A1.7070103@comodo.com> Date: Fri, 01 Jun 2012 12:21:05 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> <4FC7E512.3000801@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:21:10 -0000 On 01/06/12 08:48, denis.pinkas@bull.net wrote: > Rob, > > I do not "buy" your argumentation, since it is based on RFC 2459 which > is now obsolete and had two successors. > Also, your argumentation is defeated, simply because RFC 2459 was issued > before RFC 2560, which means before OCSP ever existed. 2459 section 3.3 describes CRLs as just "one method of certificate revocation" and then says "Message formats and protocols supporting on-line revocation notification may be defined in other PKIX specifications." So I think it's pretty clear that the authors of 2459 anticipated that new certificate revocation methods to be invented. > As I already said on the list , at the time RFC 2560 was issued, we > should have asked to ITU-T to add a OCSPsign key usage bit. At the time 2560 was issued, 2459 was in force. And 2459 says: "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information (e.g., a CRL)." OCSP Responses are "revocation information". "e.g., a CRL" doesn't mean "MUST be a CRL". So presumably the authors of 2560 believed "cRLSign" to be the applicable Key Usage bit for Integrated Responder OCSP, but didn't feel the need to express this in 2560 because 2459 already expressed it clearly. > Nobody raised the point at the proper time. It seems to me that there was no point to raise back then. 2459 was clear that "cRLSign" was the appropriate bit to set. Then 3280 came along and (it seems) changed the rules without clearly expressing (IMHO) what the new rules were. > It seems too late now. So asserting instead the DS bit is not the > perfect solution, but it is the most acceptable. > > Denis > > > > > De : Rob Stradling > A : mrex@sap.com > Cc : "pkix@ietf.org" > Date : 31/05/2012 23:39 > Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits > Envoyé par : pkix-bounces@ietf.org > ------------------------------------------------------------------------ > > > > On 31/05/12 16:59, Martin Rex wrote: > > Rob Stradling wrote: > >> > >> Are you saying that trying to "fix" the standards is not really an > option? > >> > >> What security hole would be introduced by once again allowing the > >> "crlSign" bit to authorize the CA certificate as an Integrated > Responder? > > > > This is _NOT_ a defect of rfc2560, it was a conscious design decision, > > and a careful implementor should have seen this. > > RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign > bit is asserted when the subject public key is used for verifying a > signature on revocation information (e.g., a CRL)." > > So if there was "a conscious design decision" by the RFC2560 authors > regarding which Key Usage bits should be set in the Integrated Responder > case, then surely that decision was in agreement with what I am asking > for and in disagreement with the altered text in RFCs 3280 and 5280! > > > So "fixing" does not exist as an option only changing the behaviour > > in a successor OCSP spec. But should still account for implementations > > based on rfc2560 alone. > > And what about accounting for implementations based on RFC2459 alone? > > > What is more confusing to me is that you're PKI software did not > > error on your attempt to sign OCSP responses without the > > DigitalSignature bit in your CA cert. When sensibly implemented, > > Our PKI software was written by me, and until this week I hadn't noticed > that RFC3280/5280 changed the rules on which Key Usage bit means what. > Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice > sooner. Call me a careless implementor if you like. > > >a signature creation function should perform a number of plausibility > > checks on signature creation (including KeyUsage and Validity), > > because it does not make sense (other than in very limited debug > > situations) to create digital signatures that receipients will > > very probably fail verifying. > > Let's look at this from another angle: > What would happen today if a CA decides to implement an > RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? > If they follow RFC5280's guidance, they will set keyCertSign and > digitalSignature (but NOT cRLSign) in the CA Certificate(s). > Then, what would happen when an RFC2459-compliant client attempts to > perform an OCSP check on an end-entity certificate from this PKI? If > the client enforces the RFC2459 definitions of the Key Usage bits, it > would reject the OCSP Response because the CA Certificate does not have > the cRLSign bit set!! > > > -Martin > > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > sender by replying to the e-mail containing this attachment. Replies to > this email may be monitored by COMODO for operational or business > reasons. Whilst every endeavour is taken to ensure that e-mails are free > from viruses, no liability can be accepted and the recipient is > requested to use their own virus checking software. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From rob.stradling@comodo.com Fri Jun 1 04:55:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22C21F8522 for ; Fri, 1 Jun 2012 04:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, SARE_OEM_SOFT_IS=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0Aa4HOsJSXM for ; Fri, 1 Jun 2012 04:55:07 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6309B21F851C for ; Fri, 1 Jun 2012 04:55:07 -0700 (PDT) Received: (qmail 5450 invoked from network); 1 Jun 2012 11:55:06 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Jun 2012 11:55:06 -0000 Received: (qmail 30666 invoked by uid 1000); 1 Jun 2012 11:55:06 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 01 Jun 2012 12:55:06 +0100 Message-ID: <4FC8AD99.3030705@comodo.com> Date: Fri, 01 Jun 2012 12:55:05 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: mrex@sap.com References: <20120601095014.3FD7A1A094@ld9781.wdf.sap.corp> In-Reply-To: <20120601095014.3FD7A1A094@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:55:08 -0000 On 01/06/12 10:50, Martin Rex wrote: > Rob Stradling wrote: >> >> RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign >> bit is asserted when the subject public key is used for verifying a >> signature on revocation information (e.g., a CRL)." > > Hmmmm. I think you have a point here. This definition still applies > to rfc3280 and rfc5280, actually: If we can say that OCSP Responses are a form of "certificate revocation list", then yes, the definition still applies. "(e.g., CRLs, delta CRLs, or ARLs)" certainly implies that CRLs, delta CRLs and ARLs are not necessarily the only data structures that may legitimately be called "certificate revocation lists". > http://tools.ietf.org/html/rfc3280#page-29 > > The cRLSign bit is asserted when the subject public key is used > for verifying a signature on certificate revocation list (e.g., a > CRL, delta CRL, or an ARL). This bit MUST be asserted in > certificates that are used to verify signatures on CRLs. > > http://tools.ietf.org/html/rfc5280#page-31 > > The cRLSign bit is asserted when the subject public key is used > for verifying signatures on certificate revocation lists (e.g., > CRLs, delta CRLs, or ARLs). > > > Although 2459/3280/5280 are "profiles of X.509", it seems sensible > to have it apply to technologies that were born/defined in the IETF > and not part of X.509 itself. > > >> >>> What is more confusing to me is that you're PKI software did not >>> error on your attempt to sign OCSP responses without the >>> DigitalSignature bit in your CA cert. When sensibly implemented, >> >> Our PKI software was written by me, and until this week I hadn't noticed >> that RFC3280/5280 changed the rules on which Key Usage bit means what. >> Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice >> sooner. Call me a careless implementor if you like. > > > I'm sorry, I misexplained myself. In order to make something enforcable > on the RP, it first of all will have to be enforced on the component > that creates that structure/element (=applies the signature). > > Our OEM PKI software originally refused to sign a PKCS#10 request > (request for renewal) when the current certificate was already expired, > and I had to employ a special API feature (do not check Validity when > signing) in order to obtain the signature. > > When writing PKI software, it would not be sensible to add a check to > the RP part of the software prior to ensuring that the signature > creation part enforced that feature to be correct. > > > >> >> Let's look at this from another angle: >> What would happen today if a CA decides to implement an >> RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? > > This is actually something that I consider a defect in rfc5280. > > Support of OCSP is purely optional (even less that MAY), so support of > CRLs being optional would imply that support of revocation is optional > -- which might be the reason why nobody hard-fails... > > > http://tools.ietf.org/html/rfc3280#page-49 Last paragraph of Section 5.0 > > Conforming CAs are not required to issue CRLs if other revocation or > certificate status mechanisms are provided. > > Conforming applications are NOT > REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs > with a scope other than all certificates issued by one CA. > > > -Martin > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From mrex@sap.com Fri Jun 1 05:26:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D9D11E82BB for ; Fri, 1 Jun 2012 05:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.187 X-Spam-Level: X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWH+Ts3rItGy for ; Fri, 1 Jun 2012 05:26:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 72A5811E8291 for ; Fri, 1 Jun 2012 05:26:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51CQXGZ000365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 14:26:33 +0200 (MEST) In-Reply-To: <4FC8AD99.3030705@comodo.com> To: Rob Stradling Date: Fri, 1 Jun 2012 14:26:33 +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: <20120601122633.066471A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 12:26:44 -0000 Rob Stradling wrote: > On 01/06/12 10:50, Martin Rex wrote: > > Rob Stradling wrote: > >> > >> RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign > >> bit is asserted when the subject public key is used for verifying a > >> signature on revocation information (e.g., a CRL)." > > > > Hmmmm. I think you have a point here. This definition still applies > > to rfc3280 and rfc5280, actually: > > If we can say that OCSP Responses are a form of "certificate revocation > list", then yes, the definition still applies. > > "(e.g., CRLs, delta CRLs, or ARLs)" certainly implies that CRLs, delta > CRLs and ARLs are not necessarily the only data structures that may > legitimately be called "certificate revocation lists". I agree. The use of "e.g." rather than "i.e." means that the bit is not limited to those explicitly listed. Actually, X.509 08/2005 (the one reference by rfc5280) supports this interpretationn: X.509-08/2005, Section 8.2.2.3 KeyUsage Extension (page 24) g) cRLSign: for verifying an authority's signature on CRLs. Since CRL signing is considered to be commitment to the content of the CRL by the CRL issuer, neither the digitalSignature bit nor the contentCommitment bit need be set in the certificate. If either (or both) is set, it does not affect the level of commitment the signer has endowed in the signed CRL; [...] Application specifications should indicate which of the digitalSignature or contentCommitment bits are appropriate for their use. If a signing application has no knowledge of the signer's intent regarding commitment to content, the application shall sign and support that signing with a certificate that has the digitalSignature bit set in that certificate's keyUsage extension. The latter paragraph could be interpreted to say, that when OCSP (2560) had intended to require "digitalSignature", is should have said so. But it doesn't. -Martin From mrex@sap.com Fri Jun 1 05:50:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2833311E8138 for ; Fri, 1 Jun 2012 05:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.193 X-Spam-Level: X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxh1G7rN8HS2 for ; Fri, 1 Jun 2012 05:50:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 25FDC21F87C3 for ; Fri, 1 Jun 2012 05:50:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q51CoXlM013024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 14:50:33 +0200 (MEST) In-Reply-To: <003e01cd3fd4$498ce700$dca6b500$@eu> To: Erik Andersen Date: Fri, 1 Jun 2012 14:50:32 +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: <20120601125032.F0BD91A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 12:50:36 -0000 Erik Andersen wrote: > > I am not arguing for a OCSPsign bit. However, if it is seen useful, the time > is now if we want it to be in the next edition of X.509, which is almost > finalised. Otherwise, it would be delayed probably another four years. Talking about X.509 rev. when searching through X.509 for references to OCSP, I was significantly confused by the following paragraph in X.509 11/2008 Section 7.3 Certificate Validity: Only a CA that is authorized to issue CRLs may choose to delegate that authority to another entity. If this delegation is done, it shall be verifiable at the time of certificate/CRL verification. The cRLDistributionPoints extension can be used for this purpose. The cRLIssuer field of this extension would be populated with the name(s) of any entities, other than the certificate issuer itself, that have been authorized to issue CRLs concerning the revocation status of the certificate in question. To me, that paragraph looks non-sensical. I do not see of a concept "CA that is authorized to issue CRLs" within X.509. The KeyUsage extension has a completely different purpose (usage restrictions for the accompanying key, but *NO* limits to keys further down the cert chain). -Martin From tmiller@mitre.org Fri Jun 1 06:10:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0965111E882C for ; Fri, 1 Jun 2012 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgP3dQvJ4ECK for ; Fri, 1 Jun 2012 06:10:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7628A11E8847 for ; Fri, 1 Jun 2012 06:10:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E690621B1D25; Fri, 1 Jun 2012 09:09:59 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 69D7E21B1D35; Fri, 1 Jun 2012 09:09:59 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Fri, 1 Jun 2012 09:09:59 -0400 From: "Miller, Timothy J." To: Adam Langley Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAAALdGaAAACD4AD//64bAIAAfoMAgAD1nYA= Date: Fri, 1 Jun 2012 13:09:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.138.78] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:10:25 -0000 On 5/31/12 12:30 PM, "Adam Langley" wrote: >On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J. >wrote: >> I guess I just don't see why you'd include NC in a cert but *not* mark >>it >> critical. Non-critical NC basically says "Beyond this point you should >> {only see/never see} the following names, but we don't actually care if >> you pay attention." > >The alternative is an intermediate CA certificate without any Name >Constraints at all. By including non-critical Name Constraints the >world benefits from fewer, all-powerful certificates as most clients >will enforce them. However, given the size of the Internet these days, >we can't reasonably deploy things that cause significant breakage. > >This is not ideal. Ideally we wouldn't start from where we are but, >given that we have to, I believe that this is a positive step. If NC is always critical, a conforming implementation that omits NC processing will throw errors. Implementors will have concrete incentives to fix this. Non-critical NC permits implementations to omit NC processing and still be conforming. The incentive to fix this is what, exactly? I fail to see how this is "a positive step" but maybe that's just me. -- T From mrex@sap.com Fri Jun 1 06:31:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0621F8B5F for ; Fri, 1 Jun 2012 06:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFHYpFMaChsl for ; Fri, 1 Jun 2012 06:31:15 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C725821F8B5E for ; Fri, 1 Jun 2012 06:31:14 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51DVC9b029179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 15:31:12 +0200 (MEST) In-Reply-To: To: "Miller, Timothy J." Date: Fri, 1 Jun 2012 15:31:11 +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: <20120601133111.CFDD91A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 13:31:15 -0000 Miller, Timothy J. wrote: > > If NC is always critical, a conforming implementation that omits NC > processing will throw errors. Implementors will have concrete incentives > to fix this. About as reasonable as switching off the IPv4 internet today in order to incentivize the use of IPv6, or blocking of port 80 on internet backbone routers to incentivize the use of "HTTP-over-TLS". > > Non-critical NC permits implementations to omit NC processing and still be > conforming. The incentive to fix this is what, exactly? Not implementing NC processing is *fully* conforming. > > I fail to see how this is "a positive step" but maybe that's just me. It would create a much higher market demand for a feature (NC processing) without instantly breaking the installed base. -Martin From rob.stradling@comodo.com Fri Jun 1 06:32:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088F221F8B65 for ; Fri, 1 Jun 2012 06:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnosEfLFR3di for ; Fri, 1 Jun 2012 06:32:02 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1F21F8B5E for ; Fri, 1 Jun 2012 06:32:01 -0700 (PDT) Received: (qmail 5861 invoked from network); 1 Jun 2012 13:32:00 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Jun 2012 13:32:00 -0000 Received: (qmail 16964 invoked by uid 1000); 1 Jun 2012 13:31:59 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 01 Jun 2012 14:31:59 +0100 Message-ID: <4FC8C44F.2090205@comodo.com> Date: Fri, 01 Jun 2012 14:31:59 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:32:03 -0000 On 01/06/12 14:09, Miller, Timothy J. wrote: > On 5/31/12 12:30 PM, "Adam Langley" wrote: > >> On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J. >> wrote: >>> I guess I just don't see why you'd include NC in a cert but *not* mark >>> it >>> critical. Non-critical NC basically says "Beyond this point you should >>> {only see/never see} the following names, but we don't actually care if >>> you pay attention." >> >> The alternative is an intermediate CA certificate without any Name >> Constraints at all. By including non-critical Name Constraints the >> world benefits from fewer, all-powerful certificates as most clients >> will enforce them. However, given the size of the Internet these days, >> we can't reasonably deploy things that cause significant breakage. >> >> This is not ideal. Ideally we wouldn't start from where we are but, >> given that we have to, I believe that this is a positive step. > > If NC is always critical, a conforming implementation that omits NC > processing will throw errors. Implementors will have concrete incentives > to fix this. Implementors will have concrete incentives to fix this *if* they actually ever encounter any certificates that contain Critical Name Constraints! > Non-critical NC permits implementations to omit NC processing and still be > conforming. The incentive to fix this is what, exactly? > > I fail to see how this is "a positive step" but maybe that's just me. > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From carl@redhoundsoftware.com Fri Jun 1 06:37:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3011E8107 for ; Fri, 1 Jun 2012 06:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEZTqqDhq852 for ; Fri, 1 Jun 2012 06:37:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5CA11E8089 for ; Fri, 1 Jun 2012 06:37:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1435446vbb.31 for ; Fri, 01 Jun 2012 06:37:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=WceWC9dISF+EKlfS3jErLGqezNtOD+Dp0FSW7ZHG32s=; b=ma9jfH9LH29mvYKAySFg6swuMJOv9Z3I+Rh4mjGWgD8ek4n9HhYoYl6mPN1r2vo568 Mi/2a9VvjuipkneHtxpaSiMc4bK565EvqAhCD5cMBq/oaL31OZHNeQAGpZOGo6TuG5vr 60ArQuguHtgKaFmNNRaPc+uz3JxRiVnwv7LJ4axUiL3fxDheyCc/y9xLdwRHVAv349No Xrrld4Ah8WScknWpDobQthYb0yEicI9r3Ka+JoNOHvuZwu7SH7hajEpDAHmwcPoTpSLM KvLZIKZABWkAIvbYMjEzGg0TQyIcqch/E4NNItYNETw0nhX0H9jT72KGQaKK//56Z5fs vWmQ== Received: by 10.220.240.147 with SMTP id la19mr2533009vcb.47.1338557840697; Fri, 01 Jun 2012 06:37:20 -0700 (PDT) Received: from [192.168.1.6] (pool-173-79-106-156.washdc.fios.verizon.net. [173.79.106.156]) by mx.google.com with ESMTPS id d20sm3082064vde.20.2012.06.01.06.37.17 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 06:37:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 01 Jun 2012 09:37:10 -0400 From: Carl Wallace To: "Miller, Timothy J." Message-ID: Thread-Topic: [pkix] Way Forward: Name Constraints Criticality In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkG7O9FJEbNx1Ahf4In6r8bHXWWFgBwA0liWeKglfCdSitpJQjL2+fjykjlByQ/FNZxdWrL Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:37:22 -0000 On 6/1/12 9:09 AM, "Miller, Timothy J." wrote: > >Non-critical NC permits implementations to omit NC processing and still be >conforming. No, it does not. A path validation implementation that does not support name constraints is non-conformant whether the extension is required to be critical or not. The proposed change allows CAs to generate certificates that contain name constraints extensions that will be ignored by non-conforming implementations that do not support name constraints. From tmiller@mitre.org Fri Jun 1 06:50:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD32A11E813D for ; Fri, 1 Jun 2012 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLijS-SvDwhd for ; Fri, 1 Jun 2012 06:50:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D201B11E8085 for ; Fri, 1 Jun 2012 06:50:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B03521B0C48; Fri, 1 Jun 2012 09:50:37 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2FF3321B02BA; Fri, 1 Jun 2012 09:50:37 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Fri, 1 Jun 2012 09:50:37 -0400 From: "Miller, Timothy J." To: "mrex@sap.com" Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAAALdGaAAACD4AD//64bAIAAfoMAgAD1nYCAAFnDgP//sZkA Date: Fri, 1 Jun 2012 13:50:35 +0000 Message-ID: In-Reply-To: <20120601133111.CFDD91A094@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.138.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <146C1C8F8F91E2478E5A6B1AF8ECF554@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:50:40 -0000 On 6/1/12 8:31 AM, "Martin Rex" wrote: >>I fail to see how this is "a positive step" but maybe that's just me. >It would create a much higher market demand for a feature (NC processing) >without instantly breaking the installed base. Really? How? Fairy dust? Non-critical NCs will throw no errors in all implementations (conforming or not). How will *anyone* know to pressure the implementor to add NC processing? -- T From tmiller@mitre.org Fri Jun 1 06:57:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011A711E817B for ; Fri, 1 Jun 2012 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fFUIq7hGOZ5 for ; Fri, 1 Jun 2012 06:57:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 05CED11E8106 for ; Fri, 1 Jun 2012 06:57:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A06C421B0C4E; Fri, 1 Jun 2012 09:57:02 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 93D6421B0C50; Fri, 1 Jun 2012 09:57:02 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Fri, 1 Jun 2012 09:57:02 -0400 From: "Miller, Timothy J." To: Carl Wallace Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAAALdGaAAACD4AD//64bAIAAfoMAgAD1nYCAAFtvAP//sbkA Date: Fri, 1 Jun 2012 13:57:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.138.78] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:57:04 -0000 On 6/1/12 8:37 AM, "Carl Wallace" wrote: >On 6/1/12 9:09 AM, "Miller, Timothy J." wrote: >> >>Non-critical NC permits implementations to omit NC processing and still >>be >>conforming.=20 > >No, it does not. A path validation implementation that does not support >name constraints is non-conformant whether the extension is required to be >critical or not. =20 Fair enough. Edit to read "otherwise conforming." :) >The proposed change allows CAs to generate certificates >that contain name constraints extensions that will be ignored by >non-conforming implementations that do not support name constraints. Of course, non-conformant implementations can ignore critical NCs as easily as non-critical NCs, so I still don't really see why a change is needed. -- T From mrex@sap.com Fri Jun 1 07:31:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6F11E8137 for ; Fri, 1 Jun 2012 07:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hARBvHKUxhAt for ; Fri, 1 Jun 2012 07:31:01 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A358511E8130 for ; Fri, 1 Jun 2012 07:31:00 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q51EUvKG021891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 16:30:57 +0200 (MEST) In-Reply-To: To: "Miller, Timothy J." Date: Fri, 1 Jun 2012 16:30:57 +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: <20120601143057.8484C1A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 14:31:01 -0000 Miller, Timothy J. wrote: > On 6/1/12 8:31 AM, "Martin Rex" wrote: > > >>I fail to see how this is "a positive step" but maybe that's just me. > > >It would create a much higher market demand for a feature (NC processing) > >without instantly breaking the installed base. > > Really? How? Fairy dust? Non-critical NCs will throw no errors in all > implementations (conforming or not). How will *anyone* know to pressure > the implementor to add NC processing? When Apples i/OS ignored the BasicConstraint "cA=TRUE", and this fact was publicly reported as being a security problem, it did result in a fairly quick change of the implementation -- without breaking any of the installed base. -Martin From denis.pinkas@bull.net Fri Jun 1 07:32:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C34811E8181; Fri, 1 Jun 2012 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpChtSYki-AZ; Fri, 1 Jun 2012 07:32:26 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4189511E80B0; Fri, 1 Jun 2012 07:32:26 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 4BEDE120051; Fri, 1 Jun 2012 16:32:25 +0200 (CEST) In-Reply-To: <20120601122633.066471A094@ld9781.wdf.sap.corp> References: <4FC8AD99.3030705@comodo.com> <20120601122633.066471A094@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 596CD0C8:DF8A7B67-C1257A10:004EC04A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 1 Jun 2012 16:32:24 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 01/06/2012 16:32:25, Serialize complete at 01/06/2012 16:32:25 Content-Type: multipart/alternative; boundary="=_alternative 004FB294C1257A10_=" Cc: "pkix@ietf.org" , pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:32:27 -0000 Message en plusieurs parties au format MIME --=_alternative 004FB294C1257A10_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X.509-08/2005 states: This Specification defines a Certificate Revocation=20 List (CRL) mechanism but does not preclude the use of alternative=20 mechanisms. One such alternative mechanism is the Online Certificate=20 Status Protocol (OCSP) specified in IETF RFC 2560. . Since OCSP was invented and defined by PKIX, there is no detailed=20 discussion in X.509-08/2005. So you will not find support for your claims in X.509-08/2005, even by=20 twisting its words. Denis De : mrex@sap.com (Martin Rex) A : Rob Stradling Cc : "pkix@ietf.org" Date : 01/06/2012 15:11 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits Envoy=E9 par : pkix-bounces@ietf.org Rob Stradling wrote: > On 01/06/12 10:50, Martin Rex wrote: > > Rob Stradling wrote: > >> > >> RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The=20 cRLSign > >> bit is asserted when the subject public key is used for verifying a > >> signature on revocation information (e.g., a CRL)." > > > > Hmmmm. I think you have a point here. This definition still applies > > to rfc3280 and rfc5280, actually: >=20 > If we can say that OCSP Responses are a form of "certificate revocation=20 > list", then yes, the definition still applies. >=20 > "(e.g., CRLs, delta CRLs, or ARLs)" certainly implies that CRLs, delta=20 > CRLs and ARLs are not necessarily the only data structures that may=20 > legitimately be called "certificate revocation lists". I agree. The use of "e.g." rather than "i.e." means that the bit is not limited to those explicitly listed. Actually, X.509 08/2005 (the one reference by rfc5280) supports this interpretationn: X.509-08/2005, Section 8.2.2.3 KeyUsage Extension (page 24) g) cRLSign: for verifying an authority's signature on CRLs. Since CRL signing is considered to be commitment to the content of the CRL by the CRL issuer, neither the digitalSignature bit nor the contentCommitment bit need be set in the certificate. If either (or both) is set, it does not affect the level of commitment the signer has endowed in the signed CRL; [...] Application specifications should indicate which of the digitalSignature or contentCommitment bits are appropriate for their use. If a signing application has no knowledge of the signer's intent regarding commitment to content, the application shall sign and support that signing with a certificate that has the digitalSignature bit set in that certificate's keyUsage extension. The latter paragraph could be interpreted to say, that when OCSP (2560) had intended to require "digitalSignature", is should have said so. But it doesn't. -Martin =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 004FB294C1257A10_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X.509-08/2005 states: This Specification defi= nes a Certificate Revocation List (CRL) mechanism but does  not preclude the use of alternative
mechanisms. One such alternative mechanism is the Online Certificate Status Protocol (OCSP) specified in IETF RFC 2560.
.
Since OCSP was invented and defined by PK= IX, there is no detailed discussion in X.509-08/2005.

So you will not find support for your cla= ims in X.509-08/2005, even by twisting its words.

Denis



De :     &= nbsp;  mrex@sap.com (Martin Rex)
A :     &n= bsp;  Rob Stradling <rob.strad= ling@comodo.com>
Cc :   &nb= sp;    "pkix@ietf.org&= quot; <pkix@ietf.org>
Date :    =    01/06/2012 15:11
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Rob Stradling wrote:
> On 01/06/12 10:50, Martin Rex wrote:
> > Rob Stradling wrote:
> >>
> >> RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign
> >> bit is asserted when the subject public key is used for verif= ying a
> >> signature on revocation information (e.g., a CRL)."
> >
> > Hmmmm.  I think you have a point here.  This definition still applies
> > to rfc3280 and rfc5280, actually:
>
> If we can say that OCSP Responses are a form of "certificate revocation
> list", then yes, the definition still applies.
>
> "(e.g., CRLs, delta CRLs, or ARLs)" certainly implies that CRLs, delta
> CRLs and ARLs are not necessarily the only data structures that may
> legitimately be called "certificate revocation lists".

I agree.  The use of "e.g." rather than "i.e." means that the bit is
not limited to those explicitly listed.


Actually, X.509 08/2005 (the one reference by rfc5280) supports this
interpretationn:

X.509-08/2005, Section 8.2.2.3  KeyUsage Extension (page 24)

 g) cRLSign: for verifying an authority's signature on CRLs.

    Since CRL signing is considered to be commitment to the content of
    the CRL by the CRL issuer, neither the digitalSignature bit nor the
    contentCommitment bit need be set in the certificate. If either
    (or both) is set, it does not affect the level of commitment the
    signer has endowed in the signed CRL;

    [...]

 Application specifications should indicate which of the digitalSigna= ture
 or contentCommitment bits are appropriate for their use. If a signin= g
 application has no knowledge of the signer's intent regarding commit= ment
 to content, the application shall sign and support that signing with a
 certificate that has the digitalSignature bit set in that certificat= e's
 keyUsage extension.


The latter paragraph could be interpreted to say, that when OCSP (2560)
had intended to require "digitalSignature", is should have said so.
But it doesn't.


-Martin
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 004FB294C1257A10_=-- From mrex@sap.com Fri Jun 1 07:42:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7215F11E8106; Fri, 1 Jun 2012 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjeSWGw6CnvC; Fri, 1 Jun 2012 07:42:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7811E80B4; Fri, 1 Jun 2012 07:42:33 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51EgNDN025232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 16:42:28 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Fri, 1 Jun 2012 16:42:23 +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: <20120601144223.C00011A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" , pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 14:42:34 -0000 denis.pinkas@bull.net wrote: > X.509-08/2005 states: This Specification defines a Certificate Revocation > List (CRL) mechanism but does not preclude the use of alternative > mechanisms. One such alternative mechanism is the Online Certificate > Status Protocol (OCSP) specified in IETF RFC 2560. > . > Since OCSP was invented and defined by PKIX, there is no detailed > discussion in X.509-08/2005. > > So you will not find support for your claims in X.509-08/2005, even by > twisting its words. I fail to understand what your reply refers to. X.509-08/2005 clearly states that an application should state wether it needs the DigitalSignature KeyUsage attribute asserted. The way it is worded, there is no automatic prerequisite of this KeyUsage in X.509 (different to what the name of the KeyUsage might suggest). OCSP is both, an extension to X.509 and an application based on X.509. If OCSP had a requirement for the DigitalSignature KeyUsage, it should have stated so in rfc2560. -Martin From ynir@checkpoint.com Fri Jun 1 07:46:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5954211E812E for ; Fri, 1 Jun 2012 07:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw6S8Pyb5Jba for ; Fri, 1 Jun 2012 07:46:04 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 29FF511E8126 for ; Fri, 1 Jun 2012 07:46:03 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q51EjwMO003929; Fri, 1 Jun 2012 17:45:58 +0300 X-CheckPoint: {4FC8E1DB-2-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 1 Jun 2012 17:45:56 +0300 From: Yoav Nir To: "Miller, Timothy J." Date: Fri, 1 Jun 2012 17:45:54 +0300 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac1ABUBC+zXUO6C7Q+2qjBl+/dvZSg== Message-ID: <87BB47D6-AB97-49B3-9E21-5D2FAEEDB300@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11fdfe86e6bc1f6aa8fb7d23c305f951b7f2304f31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 14:46:05 -0000 On Jun 1, 2012, at 4:09 PM, Miller, Timothy J. wrote: > On 5/31/12 12:30 PM, "Adam Langley" wrote: >=20 >> On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J. >> wrote: >>> I guess I just don't see why you'd include NC in a cert but *not* mark >>> it >>> critical. Non-critical NC basically says "Beyond this point you should >>> {only see/never see} the following names, but we don't actually care if >>> you pay attention." >>=20 >> The alternative is an intermediate CA certificate without any Name >> Constraints at all. By including non-critical Name Constraints the >> world benefits from fewer, all-powerful certificates as most clients >> will enforce them. However, given the size of the Internet these days, >> we can't reasonably deploy things that cause significant breakage. >>=20 >> This is not ideal. Ideally we wouldn't start from where we are but, >> given that we have to, I believe that this is a positive step. >=20 > If NC is always critical, a conforming implementation that omits NC > processing will throw errors. Implementors will have concrete incentives > to fix this. If the only non-supporting implementation was, say, iCab for Mac or even Op= era, you would be right. As it's the default browser on iPhone, people won't say "the iPhone is brok= en because it doesn't work with this site", but "this site is broken becaus= e it doesn't work with iPhone". The perception of which one is broken does not depend on compliance with so= me RFC, and perception drives the incentives to fix this. Now if there were a lot of websites that would be broken, then people would= blame the iPhone, but this NC feature is for corporate sub-CAs issuing cer= tificates for (mostly) intranet websites. I don't see the pressure going in= Apple's direction. Yoav From denis.pinkas@bull.net Fri Jun 1 08:05:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83021F8A70 for ; Fri, 1 Jun 2012 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLwhjyXRQF6u for ; Fri, 1 Jun 2012 08:05:20 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7A21F8A6F for ; Fri, 1 Jun 2012 08:05:20 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id A34C512004A; Fri, 1 Jun 2012 17:05:19 +0200 (CEST) In-Reply-To: <20120601144223.C00011A094@ld9781.wdf.sap.corp> References: <20120601144223.C00011A094@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 9D2C3BE5:0E923A87-C1257A10:00520DB8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 1 Jun 2012 17:05:18 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 01/06/2012 17:05:19, Serialize complete at 01/06/2012 17:05:19 Content-Type: multipart/alternative; boundary="=_alternative 0052E0ECC1257A10_=" Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 15:05:21 -0000 Message en plusieurs parties au format MIME --=_alternative 0052E0ECC1257A10_= Content-Type: text/plain; charset="US-ASCII" Martin, Please refer to the previous emails and my presentation at the last PKIX meeting: RFC 2560 is wrong and ambiguous. In a perfect world, we should have defined an OCSPsign key usage bit. We failed to do it, or simply we did'nt. Do you believe we should define it now ? If yes, what kind of migration path would you suggest ? If your answer to the first question is no, then the most reasonable solution is to request the assertion of bit 0 (data origin authentication) in the key usage extension when a CA directly signs OCSP responses. Denis De : mrex@sap.com (Martin Rex) A : denis.pinkas@bull.net Cc : mrex@sap.com, "pkix@ietf.org" , pkix-bounces@ietf.org, Rob Stradling Date : 01/06/2012 16:42 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits denis.pinkas@bull.net wrote: > X.509-08/2005 states: This Specification defines a Certificate Revocation > List (CRL) mechanism but does not preclude the use of alternative > mechanisms. One such alternative mechanism is the Online Certificate > Status Protocol (OCSP) specified in IETF RFC 2560. > . > Since OCSP was invented and defined by PKIX, there is no detailed > discussion in X.509-08/2005. > > So you will not find support for your claims in X.509-08/2005, even by > twisting its words. I fail to understand what your reply refers to. X.509-08/2005 clearly states that an application should state wether it needs the DigitalSignature KeyUsage attribute asserted. The way it is worded, there is no automatic prerequisite of this KeyUsage in X.509 (different to what the name of the KeyUsage might suggest). OCSP is both, an extension to X.509 and an application based on X.509. If OCSP had a requirement for the DigitalSignature KeyUsage, it should have stated so in rfc2560. -Martin --=_alternative 0052E0ECC1257A10_= Content-Type: text/html; charset="US-ASCII" Martin,

Please refer to the previous emails and my presentation at the last PKIX meeting: RFC 2560 is wrong and ambiguous.

In a perfect world, we should have defined an OCSPsign key usage bit. We failed to do it, or simply we did'nt.

Do you believe we should define it now ?
If yes, what kind of migration path would you suggest ?
 
If your answer to the first question is no, then the most reasonable solution is to request the assertion of  bit 0
(data origin authentication) in the key usage extension when a CA directly signs OCSP responses.

Denis




De :        mrex@sap.com (Martin Rex)
A :        denis.pinkas@bull.net
Cc :        mrex@sap.com, "pkix@ietf.org" <pkix@ietf.org>, pkix-bounces@ietf.org, Rob Stradling <rob.stradling@comodo.com>
Date :        01/06/2012 16:42
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits



denis.pinkas@bull.net wrote:
> X.509-08/2005 states: This Specification defines a Certificate Revocation
> List (CRL) mechanism but does  not preclude the use of alternative
> mechanisms. One such alternative mechanism is the Online Certificate
> Status Protocol (OCSP) specified in IETF RFC 2560.
> .
> Since OCSP was invented and defined by PKIX, there is no detailed
> discussion in X.509-08/2005.
>
> So you will not find support for your claims in X.509-08/2005, even by
> twisting its words.

I fail to understand what your reply refers to.

X.509-08/2005 clearly states that an application should state wether
it needs the DigitalSignature KeyUsage attribute asserted.  The way
it is worded, there is no automatic prerequisite of this KeyUsage
in X.509 (different to what the name of the KeyUsage might suggest).

OCSP is both, an extension to X.509 and an application based on X.509.
If OCSP had a requirement for the DigitalSignature KeyUsage, it should
have stated so in rfc2560.

-Martin
--=_alternative 0052E0ECC1257A10_=-- From mrex@sap.com Fri Jun 1 08:13:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4446511E81F4 for ; Fri, 1 Jun 2012 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.913 X-Spam-Level: X-Spam-Status: No, score=-9.913 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77fMn63lSUso for ; Fri, 1 Jun 2012 08:13:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7881F11E81A9 for ; Fri, 1 Jun 2012 08:13:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51FDfAm003567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 17:13:41 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Fri, 1 Jun 2012 17:13:41 +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: <20120601151341.42A5E1A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 15:13:44 -0000 denis.pinkas@bull.net wrote: > > Please refer to the previous emails and my presentation at the last PKIX > meeting: RFC 2560 is wrong and ambiguous. > > In a perfect world, we should have defined an OCSPsign key usage bit. We > failed to do it, or simply we did'nt. > > Do you believe we should define it now ? > If yes, what kind of migration path would you suggest ? > > If your answer to the first question is no, then the most reasonable > solution is to request the assertion of bit 0 > (data origin authentication) in the key usage extension when a CA directly > signs OCSP responses. After re-reading the existing specification (X.509 and PKIX) I have *NOT* found a rationale why an RP could reject an OCSP response signed by a CA cert that does not have DigitalSignature asserted. Retrofitting an additional requirement for issuing CAs about certs that should be permitted to sign OCSP responses in conjunction with an additional requiremnt for RPs to check, does not make any sense at this point in time for implementations based on rfc2560. -Martin From hallam@gmail.com Fri Jun 1 09:51:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F019F11E80FE for ; Fri, 1 Jun 2012 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S1z6X4Wt9AL for ; Fri, 1 Jun 2012 09:51:31 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9911E80E3 for ; Fri, 1 Jun 2012 09:51:23 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so3579723obb.31 for ; Fri, 01 Jun 2012 09:51:22 -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 :cc:content-type; bh=3BkDfkeWlCNXpmxYynBuw6wJFhKJeRt25VIL2McdUo0=; b=hHkQRx4g2jMgOYTNqThhoQ8W7/EtgM4a03TzP/not2J6jUrEmQEQaBHFvQ9sYi3lHB s57wygKWpINKTxCb5zpB3M7fJa6vGW428WDcl/k8xuD4W5Fk2XiugzLUFitOSFOyIkpv SyRddGOmfe56JxQfvALFhTRrXdZlrTdMQXXIlH1fGcoSvmKVy+OdWrBJZQKZM2QVuY5b 0YCFMf+OGTUeGE3wcM+0n/GA1/atNqaWiqlArVpcuAs2zEK+DC0CxLlu2Fod6kgpOSno RoPVShiRcJC4kFu3P/zyOCvA9PI8iU6VsvY+7U01rz6aXmFMbSNknedR91h/KJW7zxu+ Oiyw== MIME-Version: 1.0 Received: by 10.182.40.71 with SMTP id v7mr3498952obk.5.1338569482854; Fri, 01 Jun 2012 09:51:22 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Fri, 1 Jun 2012 09:51:22 -0700 (PDT) In-Reply-To: References: <20120601133111.CFDD91A094@ld9781.wdf.sap.corp> Date: Fri, 1 Jun 2012 12:51:22 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: multipart/alternative; boundary=f46d04446c11885f8a04c16bfebb Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:51:32 -0000 --f46d04446c11885f8a04c16bfebb Content-Type: text/plain; charset=ISO-8859-1 In the parlance that has become fashionable. Legacy Android and Safari are too big to fail. We cannot issue certs that are incompatible with the deployed base, Apple has no incentive to deploy code that checks NCs that will never appear in issued certs. If you want NCs implemented, the only way to do that is either (1) to make it possible for CAs to start issuing them now and then persuade Apple to take advantage of a control that is already being implemented in deployed certs or (2) persuade them that they would like to provide native support for bridge CA in Safari. The CAs cannot lead the market in technical standards in the way you seem to think. We can't even shut off SHA1 or RSA1024 without going through a huge amount of hassle. We can tell people what we think they SHOULD do but we can't force them to do that by refusing to issue certs that support their products. On Fri, Jun 1, 2012 at 9:50 AM, Miller, Timothy J. wrote: > On 6/1/12 8:31 AM, "Martin Rex" wrote: > > >>I fail to see how this is "a positive step" but maybe that's just me. > > >It would create a much higher market demand for a feature (NC processing) > >without instantly breaking the installed base. > > Really? How? Fairy dust? Non-critical NCs will throw no errors in all > implementations (conforming or not). How will *anyone* know to pressure > the implementor to add NC processing? > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --f46d04446c11885f8a04c16bfebb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the parlance that has become fashionable. Legacy Android and Safari are = too big to fail. We cannot issue certs that are incompatible with the deplo= yed base, Apple has no incentive to deploy code that checks NCs that will n= ever appear in issued certs.

If you want NCs implemented, the only way to do that is eith= er (1) to make it possible for CAs to start issuing them now and then persu= ade Apple to take advantage of a control that is already being implemented = in deployed certs or (2) persuade them that they would like to provide nati= ve support for bridge CA in Safari.


The CAs cannot lead the market in techni= cal standards in the way you seem to think. We can't even shut off SHA1= or RSA1024 without going through a huge amount of hassle.

We can tell people what we think they SHOULD do but we can&#= 39;t force them to do that by refusing to issue certs that support their pr= oducts.


On Fri, Jun 1, 2012 at= 9:50 AM, Miller, Timothy J. <tmiller@mitre.org> wrote:
On 6/1/12 8:31 AM, "M= artin Rex" <mrex@sap.com> wr= ote:

>>I fail to see how this is "a positive step" but maybe tha= t's just me.

>It would create a much higher market demand for a feature (NC pro= cessing)
>without instantly breaking the installed base.

Really? =A0How? =A0Fairy dust? =A0Non-critical NCs will throw no errors in = all
implementations (conforming or not). =A0How will *anyone* know to pressure<= br> the implementor to add NC processing?

-- T

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



--
= Website: http://hallambaker.com/
--f46d04446c11885f8a04c16bfebb-- From mstjohns@comcast.net Fri Jun 1 11:52:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16D911E80A4 for ; Fri, 1 Jun 2012 11:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM2N04NrATpN for ; Fri, 1 Jun 2012 11:52:38 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id CDC1211E80A3 for ; Fri, 1 Jun 2012 11:52:37 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta09.westchester.pa.mail.comcast.net with comcast id H6rF1j00817dt5G596sduM; Fri, 01 Jun 2012 18:52:37 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta13.westchester.pa.mail.comcast.net with comcast id H6sc1j00V57vnMg3Z6scBE; Fri, 01 Jun 2012 18:52:37 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Jun 2012 14:52:33 -0400 To: Yoav Nir ,"Miller, Timothy J." From: Michael StJohns In-Reply-To: <87BB47D6-AB97-49B3-9E21-5D2FAEEDB300@checkpoint.com> References: <87BB47D6-AB97-49B3-9E21-5D2FAEEDB300@checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120601185237.CDC1211E80A3@ietfa.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 18:52:39 -0000 At 10:45 AM 6/1/2012, Yoav Nir wrote: >As it's the default browser on iPhone, people won't say "the iPhone is broken because it doesn't work with this site", but "this site is broken because it doesn't work with iPhone". There are plenty of sites that are broken with respect to the iPhone - the ones that have FLASH instead of Quicktime or HTML5. Please don't use the iPhone as an excuse here. And I was told a while back that the uptake for iPhone patches is near 100% within 2 weeks of release. So if enough things break maybe Apple will "do the right thing" quickly. Mike From yngve@opera.com Fri Jun 1 12:15:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA21F11E811C for ; Fri, 1 Jun 2012 12:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgZtCxIjW4Kx for ; Fri, 1 Jun 2012 12:15:56 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id EA30111E80A4 for ; Fri, 1 Jun 2012 12:15:55 -0700 (PDT) Received: from acorna.invalid.invalid (106.170.202.84.customer.cdi.no [84.202.170.106]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q51JFgjU003052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2012 19:15:43 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Yoav Nir" , "Miller, Timothy J." , "Michael StJohns" References: <87BB47D6-AB97-49B3-9E21-5D2FAEEDB300@checkpoint.com> <20120601185237.CDC1211E80A3@ietfa.amsl.com> Date: Fri, 01 Jun 2012 21:15:57 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <20120601185237.CDC1211E80A3@ietfa.amsl.com> User-Agent: Opera Mail/11.64 (Win32) Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:15:56 -0000 On Fri, 01 Jun 2012 20:52:33 +0200, Michael StJohns wrote: > At 10:45 AM 6/1/2012, Yoav Nir wrote: >> As it's the default browser on iPhone, people won't say "the iPhone is >> broken because it doesn't work with this site", but "this site is >> broken because it doesn't work with iPhone". > > > There are plenty of sites that are broken with respect to the iPhone - > the ones that have FLASH instead of Quicktime or HTML5. I think there is a "slight" difference between a *site operator* breaking interoperability, in part or completely, with any browser (they might not consider those browser users relevant markets, or they might not know better, in any case it is their loss), and the site's *certificate provider* breaking the site's current interoperability with a significant or large portion of their market by effectively denying service to those visitors. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From turners@ieca.com Fri Jun 1 12:25:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD511E80BD for ; Fri, 1 Jun 2012 12:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSb0QJkL1zOl for ; Fri, 1 Jun 2012 12:25:11 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.66.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4514811E808A for ; Fri, 1 Jun 2012 12:24:59 -0700 (PDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 9A168793FB002 for ; Fri, 1 Jun 2012 14:24:58 -0500 (CDT) Received: from [71.191.8.30] (port=40666 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaXSz-0001Zp-Ld; Fri, 01 Jun 2012 14:24:58 -0500 Message-ID: <4FC91705.50403@ieca.com> Date: Fri, 01 Jun 2012 15:24:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <20120103200025.6720.30648.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.8.30]:40666 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:25:12 -0000 Denis, Apologies for taking forever to get back to this. I hope to have the next version out soon. spt On 1/10/12 11:43 AM, denis.pinkas@bull.net wrote: > 12 comments on draft-ietf-pkix-cmc-serverkeygeneration-00.txt > CMC Extensions: Server Key Generation > > > 1) A vulnerability analysis is missing and thus security requirements > are missing. Always interesting trying to answer this kind of comment :) I'll readily admit the security considerations need to be beefed up. I've added some text in my working copy that will hopefully address this. > 2) The advantages and disadvantages of each method is not discussed or > explained before the methods are introduced. In my working copy there's about an additional page of text to go over some of the advantages and disadvantages of each method. > 3) The security considerations section states: “POP is extremely > important”. > However, the text placed after does not provide a rational: > > “However, POP here is different than in > client-generated key certification requests in that the POP is > necessary to prove to the server that the client has possession of > the private key necessary to decrypt the server-generated private key > rather than possess the private key associated with the public key in > the request. > > If the client does not possess the private key, he will not be able to > decrypt the private key > and thus there is no harm. IMO, POP is unnecessary. This will lead to > many simplifications on the document. I think Jim and Russ answered this one. I've worked up a bunch of text to explain that the POP we were talking about is not POP for the key returned from the server. If you're going to do POP for the server-generated key an additional roundtrip is required. I also now tend to agree that the POP we were talking is more as you characterize. However, I want to keep the option for CAs to require that clients show they've got the private key needed to decrypt the key. In my working copy, I've got aome text to address this. > 4) How replay protection of the messages is achieved is not explained, > even in the security considerations section. We'll add some text. > 5) The text states in section 1.1.1: > > “The shared secret allows the server to authenticate the client and > allows the server to encrypt > the server-side generated key for the client”. > > This is not very secure. If the shared key is discovered, then all > previous private keys may be decrypted. > There should be a static key derived from the shared key to be used for > authentication and > an ephemeral key derived from the shared key and from a random (thus the > encryption key is different > for every private key). The derivation function should be one way. The > derivation methods should be part > of the specification. We did point this out as an issue in the security considerations (last paragraph). The problem is that if you use a shared secret to provide the security, it doesn't matter how many different ways we derive the key if the master is disclosed. This is one of the reasons you'd use the public key option. > 6) The text states in section 1.1.1: > > “The shared secret allows the server to authenticate the client and > allows the server to encrypt > the server-side generated key for the client. The shared secret is > distributed via an out-of-band > mechanism that is out-of-scope of this document”. > > This is insufficient. There is a need to distribute IDs and shared > secrets so that the server > may select the right key when it receives a request. The ID must be part > of the request. You're right we'll add that the IDs need to be distributed and we'll add it in the requests. > 7) The text states in section 1.1.1: > > “The client can validate that the response came from the CA by > validating the digital signature on the SignedData to a Trust Anchor > (TA)”. > > No. The client must validate that the response came from the CA using > the authentication key. I disagree on this. There's a chance the key was actually generated by the RA and verifying the authentication key wouldn't tell you it came from the CA. > 8) The text states in section 1.1.2: > > “POP is necessary because the client would like the > response encrypted with a public key and the server must determine > that the client actually has the private key associated with the > public key.” > > POP is not necessary. See above. Hopefully, I'll have this all fixed up in the next version. > 9) Typo on page 7, last line before the end of the page. > Replace “date” by “data”. fixed in my working copy > 10) The text states in section 2.1 on page 14: > > “When this method is used with the certificate option, the server MUST > validate the certificate back to a trust anchor. Further, the server > MUST check that the client provided certificate belongs to the same > client that authenticated the certificate request (e.g. the > certificate subjects match, or the client provided certificate > belongs to the same entity as the authentication shared secret). If > either of these checks fails, then the server MUST return a > CMCFailInfo with the value of badCertificate, which is defined in > Section 5”. > > This is not necessary. This paragraph should be deleted. I think validating back to a trust anchor is a valuable step. Otherwise, why wouldn't you just use the uncertified public key. > 11) The text states in section 2.2 on page 15: > > “In general, while it > is expected that the same identity token and shared secret used to do > the identity authentication are used to derive the key encryption key > this is not required”. > > As stated earlier, the use of the same key shall not be possible. This text doesn't state that the same key is derived. > 12) The text states in section 6 on page 20: > > “Cryptographic algorithms and keys used to protect the private key > should be at least as strong as the private key's intended strength”. > > A separate discussion on the strength of the authentication key and of > the encryption key is needed. How about we point to RFC 3766 and maybe NIST SP800-57? Again, apologies for taking too long to get to this. From rob.stradling@comodo.com Fri Jun 1 12:49:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E5711E80A4 for ; Fri, 1 Jun 2012 12:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0ULEoM+fSmF for ; Fri, 1 Jun 2012 12:49:21 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1A99211E80A0 for ; Fri, 1 Jun 2012 12:49:20 -0700 (PDT) Received: (qmail 22127 invoked from network); 1 Jun 2012 19:49:19 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Jun 2012 19:49:19 -0000 Received: (qmail 5575 invoked by uid 1000); 1 Jun 2012 19:49:18 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 01 Jun 2012 20:49:18 +0100 Message-ID: <4FC91CBE.8050507@comodo.com> Date: Fri, 01 Jun 2012 20:49:18 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: mrex@sap.com References: <20120601151341.42A5E1A094@ld9781.wdf.sap.corp> In-Reply-To: <20120601151341.42A5E1A094@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:49:22 -0000 On 01/06/12 16:13, Martin Rex wrote: > denis.pinkas@bull.net wrote: >> >> Please refer to the previous emails and my presentation at the last PKIX >> meeting: RFC 2560 is wrong and ambiguous. >> >> In a perfect world, we should have defined an OCSPsign key usage bit. We >> failed to do it, or simply we did'nt. >> >> Do you believe we should define it now ? >> If yes, what kind of migration path would you suggest ? >> >> If your answer to the first question is no, then the most reasonable >> solution is to request the assertion of bit 0 >> (data origin authentication) in the key usage extension when a CA directly >> signs OCSP responses. > > After re-reading the existing specification (X.509 and PKIX) I have > *NOT* found a rationale why an RP could reject an OCSP response signed > by a CA cert that does not have DigitalSignature asserted. Thanks Martin. Maybe I should just stop worrying about this issue then. > Retrofitting an additional requirement for issuing CAs about certs > that should be permitted to sign OCSP responses in conjunction with > an additional requiremnt for RPs to check, does not make any sense > at this point in time for implementations based on rfc2560. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mstjohns@comcast.net Fri Jun 1 13:29:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A4411E80B4 for ; Fri, 1 Jun 2012 13:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlbhnBUbnpIN for ; Fri, 1 Jun 2012 13:29:36 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFCD21F8745 for ; Fri, 1 Jun 2012 13:29:35 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id H7j61j0050bG4ec598VbRL; Fri, 01 Jun 2012 20:29:35 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta03.westchester.pa.mail.comcast.net with comcast id H8Vb1j00157vnMg3P8Vb76; Fri, 01 Jun 2012 20:29:35 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Jun 2012 16:29:32 -0400 To: "Yngve N. Pettersen (Developer Opera Software ASA)" , "Yoav Nir" , "Miller, Timothy J." From: Michael StJohns In-Reply-To: References: <87BB47D6-AB97-49B3-9E21-5D2FAEEDB300@checkpoint.com> <20120601185237.CDC1211E80A3@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120601202936.0EFCD21F8745@ietfa.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:29:36 -0000 You're looking at the wrong end of things. In both cases, the "breaking" is not due to the site operator (who chooses to use FLASH or gets their cert from someone who includes an NC), but in the support available at the browser. I.e. the *site* chooses the *site certificate provider*. The *site* chooses the technology. Mike At 03:15 PM 6/1/2012, Yngve N. Pettersen (Developer Opera Software ASA) wrote: >On Fri, 01 Jun 2012 20:52:33 +0200, Michael StJohns >wrote: > >>At 10:45 AM 6/1/2012, Yoav Nir wrote: >>>As it's the default browser on iPhone, people won't say "the iPhone is >>>broken because it doesn't work with this site", but "this site is >>>broken because it doesn't work with iPhone". >> >> >>There are plenty of sites that are broken with respect to the iPhone - >>the ones that have FLASH instead of Quicktime or HTML5. > >I think there is a "slight" difference between a *site operator* breaking >interoperability, in part or completely, with any browser (they might not >consider those browser users relevant markets, or they might not know >better, in any case it is their loss), and the site's *certificate >provider* breaking the site's current interoperability with a significant >or large portion of their market by effectively denying service to those >visitors. > >-- >Sincerely, >Yngve N. Pettersen >******************************************************************** >Senior Developer Email: yngve@opera.com >Opera Software ASA http://www.opera.com/ >Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 >******************************************************************** From hartmans@mit.edu Fri Jun 1 14:22:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275E821F889E for ; Fri, 1 Jun 2012 14:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1pqRZoNnwlL for ; Fri, 1 Jun 2012 14:22:20 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1735921F889D for ; Fri, 1 Jun 2012 14:22:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C3AE4202D8; Fri, 1 Jun 2012 17:22:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BC5F24151; Fri, 1 Jun 2012 17:22:14 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <4FC6AEDA.4010709@cs.tcd.ie> Date: Fri, 01 Jun 2012 17:22:14 -0400 In-Reply-To: <4FC6AEDA.4010709@cs.tcd.ie> (Stephen Farrell's message of "Thu, 31 May 2012 00:35:54 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pkix , "krb-wg mailing list \(ietf-krb-wg@lists.anl.gov\)" Subject: Re: [pkix] [Ietf-krb-wg] RFC 5742 review of draft-hotz-kx509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:22:21 -0000 >>>>> "Stephen" == Stephen Farrell writes: Hi. I believe that this issue has been discussion in the Kerberos working group and we asked the author to document the existing KX509 protocol and publish that so we'd have a historical record of what is done today. It's likely we'll do work in this space in the future but it's our desire that work be informed by an existing historical record and the current draft will help us with that. So, with my chair hat on, I believe this has already been discussed in Kerberos and we support publication. Which is to say, no conflict here. Stephen> I'll take silence as meaning that nobody thinks that Stephen> there's a conflict. If someone thinks there is a conflict Stephen> let me, the list, or the wg chairs know. In due course, Stephen> I'll be doing my own evaluation as well of course, as will Stephen> other IESG members. Stephen> Thanks, Stephen. Stephen> [1] http://tools.ietf.org/html/draft-hotz-kx509-04 [2] Stephen> http://tools.ietf.org/html/rfc5742 Stephen> _______________________________________________ ietf-krb-wg Stephen> mailing list ietf-krb-wg@lists.anl.gov Stephen> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg From rob.stradling@comodo.com Fri Jun 1 15:01:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BDE11E8097 for ; Fri, 1 Jun 2012 15:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX8lIiYujrfk for ; Fri, 1 Jun 2012 15:01:15 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 685AC11E80F3 for ; Fri, 1 Jun 2012 15:01:13 -0700 (PDT) Received: (qmail 16843 invoked from network); 1 Jun 2012 22:01:12 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Jun 2012 22:01:12 -0000 Received: (qmail 22249 invoked by uid 1000); 1 Jun 2012 22:01:11 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 01 Jun 2012 23:01:11 +0100 Message-ID: <4FC93BA7.2020900@comodo.com> Date: Fri, 01 Jun 2012 23:01:11 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20120601133111.CFDD91A094@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 22:01:16 -0000 FWIW, Apple just voted in favour of allowing non-critical Name Constraints (in the CABForum ballot currently being conducted on the public CABForum list). On 01/06/12 17:51, Phillip Hallam-Baker wrote: > In the parlance that has become fashionable. Legacy Android and Safari > are too big to fail. We cannot issue certs that are incompatible with > the deployed base, Apple has no incentive to deploy code that checks NCs > that will never appear in issued certs. > > If you want NCs implemented, the only way to do that is either (1) to > make it possible for CAs to start issuing them now and then persuade > Apple to take advantage of a control that is already being implemented > in deployed certs or (2) persuade them that they would like to provide > native support for bridge CA in Safari. > > > The CAs cannot lead the market in technical standards in the way you > seem to think. We can't even shut off SHA1 or RSA1024 without going > through a huge amount of hassle. > > We can tell people what we think they SHOULD do but we can't force them > to do that by refusing to issue certs that support their products. > > > On Fri, Jun 1, 2012 at 9:50 AM, Miller, Timothy J. > wrote: > > On 6/1/12 8:31 AM, "Martin Rex" > > wrote: > > >>I fail to see how this is "a positive step" but maybe that's just me. > > >It would create a much higher market demand for a feature (NC > processing) > >without instantly breaking the installed base. > > Really? How? Fairy dust? Non-critical NCs will throw no errors in all > implementations (conforming or not). How will *anyone* know to pressure > the implementor to add NC processing? > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > > -- > Website: http://hallambaker.com/ > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From paul.hoffman@vpnc.org Fri Jun 1 16:49:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D49911E80F3 for ; Fri, 1 Jun 2012 16:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9TwWqi4Ux8O for ; Fri, 1 Jun 2012 16:49:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C610B11E8111 for ; Fri, 1 Jun 2012 16:49:15 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q51Nn9pF004998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Jun 2012 16:49:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 1 Jun 2012 16:49:08 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6E9CF5F1-0E93-49C5-81CE-FA31695A3049@vpnc.org> References: To: IETF PKIX X-Mailer: Apple Mail (2.1278) Subject: Re: [pkix] WGLC for draft-ietf-pkix-caa-07 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 23:49:16 -0000 On May 31, 2012, at 11:55 AM, Stephen Kent wrote: > Having read through the backlog of mail I see that PHB has requested > WGLC for draft-ietf-pkix-caa-07. > > So, the WGLC begins tomorrow (6/1) and completes on 6/15. I have read the latest version of the document and it seems fine. --Paul Hoffman From i.grok@comcast.net Sat Jun 2 16:13:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD54E11E8074 for ; Sat, 2 Jun 2012 16:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWbnuIIyLAn1 for ; Sat, 2 Jun 2012 16:13:57 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id A4FCC11E8072 for ; Sat, 2 Jun 2012 16:13:57 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta15.emeryville.ca.mail.comcast.net with comcast id HbDu1j0050FhH24AFbDxJ8; Sat, 02 Jun 2012 23:13:57 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta08.emeryville.ca.mail.comcast.net with comcast id HbDu1j00Y00PQ6U8UbDwto; Sat, 02 Jun 2012 23:13:57 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q52NDrml016613 for ; Sat, 2 Jun 2012 19:13:53 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q52NDrPI016612 for pkix@ietf.org; Sat, 2 Jun 2012 19:13:53 -0400 Date: Sat, 2 Jun 2012 19:13:53 -0400 From: Scott Schmit To: pkix@ietf.org Message-ID: <20120602231353.GA16209@odin.ulthar.us> Mail-Followup-To: pkix@ietf.org References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] WGLC X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 23:13:59 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 31, 2012 at 02:55:35PM -0400, Stephen Kent wrote: > Having read through the backlog of mail I see that PHB has requested > WGLC for draft-ietf-pkix-caa-07. In summary: Terminology is used inconsistently, and in some cases new terms are created when existing ones would do (or so it seems, as I don't fully understand this I-D). Terms are also defined unclearly, or have examples (apparently) inconsistent with the definitions. Most of this document is unclear on first reading. Terms, formats, etc are used before they are defined. I suppose if I read this again, I might understand it better, but I shouldn't have to. As it is, I had to re-read many sections 2-4 times before I got to where I thought I understood them. I'm especially confused about where I'm allowed/supposed to place CAA records in the DNS, and what effect it will have if I do so (largely due to section 3 being very unclear). I'm also unclear how binary data/value fields are handled in presentation format. Most everything else I think I understood eventually. Now for the specifics: Section 1.2: =46rom 2.1: > Critical If set, indicates that the corresponding property entry tag > MUST be understood if the semantics of the CAA record are to be > correctly understood by the specified audience. > > Issuers MUST NOT issue certificates for a domain if the Extended > Issuer Authorization Set contains unknown property entry tags that > have both the Issuer and Critical bits set. What "Issuer" bit/flag? There is no such bit/flag defined. > The following properties are defined: > > issue [; ]* The issue property entry > declares an authorization entry granting authorization to issue to ^^ > the holder of the specified domain name or a party acting under > the express written authority of the holder of the domain name. =2E.. > The following example informs CAs that certificates MUST NOT be > issued except by the holder of the domain name 'ca.example.net' or an ^^ ^^^^^^^^^^^^^^ > authorized agent thereof. Since the policy is published at the > Public Delegation Point, the policy applies to all subordinate > domains under example.com. > > $ORIGIN example.com > . CAA 0 issue "ca.example.net" This appears to contradictory. I'm guessing that the latter is correct, and the "specified domain name" in the earlier paragraph isn't referring to the "" field. It should probably be "issue " and the following text should clarify between the CA domain name and the domain that the record is for. I'm not sure I like that examples of CAA RRs are provided before the syntax of the CAA record has actually been defined--it's making this very hard to understand. The definition for Public Delegation Point is unhelpful to me. What's a "Top Level Directory"? Is this a TLD? (TLD expands to Top-Level Domain, not Directory). Apparently not, since example.com isn't a TLD, so what is it? How does an issuer know if a given domain is a registry/public delegation point or not? If you mean to say that parent domains can set CAA records for their subdomains, just say so--don't invent new terms for it. Honestly, the document is a mess of terminology and jargon. In section 2.1, we have "property entries", "flags", "properties", and "tag-value pairs". In section 3, we also have "[CAA] Authorization Entry", "Extended Issuer Authorization Set", and "Issuer Authorization Set", etc which are defined, but not in the same terms as in section 2.1. They seem to overlap in meaning with the terms in section 2.1, but might not. I don't know. Section 3: The definition of Extended Issuer Authorization Set (EIAS) is unnecessarily complex. The definition in 1.2 implies that my parent domain (or PDP) can set CAA records that apply to me (otherwise the "extended" terminology doesn't make any sense) but a straightforward reading of the definition in this section says that CAA records can only be set on domains immediately below a TLD (or a CCTLD SLD). (I think that's what you mean by PDP.) That's conveniently the same set of entities that public CAs will issue certificates for (AFAICT)--domains with entries in a whois database. So why all this convoluted terminology & indirection for determining if a CAA record is valid or not when what it really comes down to is "CAA records on the domain that an issuer is willing to consider issuing certs for"? Or if you don't want to be that loose about it for some reason, then say "CAA records are only valid on domains delegated to by registries". That should save at least a page of text. But your example in section 3 implies I've misread again, because according to your rules, caa.example.com's EIAS is empty, but your example claims otherwise. I'll let someone explain where I misparsed. Section 3.1 You went through the trouble of defining canonical names abstractly (I thought to make it possible to handle future BNAME, SHADOW, or whatever records in the future), but then explicitly call out CNAME and DNAME here. If a future BNAME comes about, there is no requirement to process such records correctly. Therefore you don't need the definitions in 1.2. Section 4.1: I think you're mixing up "tag value pairs" and "properties" compared to the discussion of this in section 2.1--the syntax shown there allow there to be zero or more tag-value pairs. However, the first sentence here say that there is only one per RR. In 2.1-speak, you have one property per RR. > +0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| > | Flags | Tag Length =3D n | > +----------------+----------------+...+---------------+ > | Tag char 0 | Tag Char 1 |...| Tag Char n-1 | > +----------------+----------------+...+---------------+ > +----------------+----------------+.....+---------------+ > | Data byte 0 | Data byte 1 |.....| Data byte m-1 | > +----------------+----------------+.....+---------------+ The formatting of the wire format causes me to overlook the flags & tag length fields. Even when I know they're there, I still tend to ignore them. > Where n is the length specified in the tag length field and m is the > remaining octets in the data field (m =3D d - n - 2) where d is the > length of the data section. d is never used in the figure. What is "the length of the data section"? Is it the size of the RDATA (RDLENGTH) or the number of data bytes? Assuming your equation is right, it's the former. I'd recommend a presentation more like what's shown in RFC 1035: > 1 1 1 1 1 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | | > / / > / NAME / > | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | TYPE | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | CLASS | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | TTL | > | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > | RDLENGTH | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| > / RDATA / > / / > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ (Especially since your RRtype is mostly variable-length fields.) The critical flag is called Issuer Critical Flag here, but just "Critical [Flag]" in section 2.1. > Tag The property identifier, a sequence of ASCII characters. > > Tag values MAY contain ASCII characters a through z and the > numbers 0 through 9. Tag values MUST NOT contain any other > characters. Matching of tag values is case insensitive. Are you sure you don't want to include dashes? What if you want to define a tag with multiple words in it in the future? I guess you could just do camelcase. > Tag Length A single octet containing an unsigned integer specifying > the tag length in octets. The tag length MUST be at least 1 and > SHOULD be no more than 15. Making the max tag length a SHOULD seems useless to me. If I'm implementing software that parses the RR (but doesn't process it), I must assume that the tag length could be 255, or I'll break if another CAA specification comes out that creates a tag > 15 bytes long. If I'm processing the record, I could ignore CAA records with tag lengths not equal to the lengths of any tags I recognize (I won't be able to process the records anyway), but then the limitation on tag length doesn't really help me out either. > Value A sequence of octets representing the property value. > Property values are encoded as binary values and MAY employ sub- > formats. Ok, so above, in your wire format, there is nothing labeled "Value" or even "Value byte". Below, in your presentation format, there is no "Value" either--just data. Section 4.1.1: Again, "tag" isn't defined consistently with section 2.1. Assuming that data =3D "Value" above, data can be a binary field. > CAA =2E.. > data Is the ascii text Encoding of the value field What does "ascii text Encoding of the value field" mean? Does that mean that it'll be one of "US-ASCII", "UTF-8", etc? If so, where does the value go? If data =3D Value, then since Value can be binary data, what encoding is it? That either means (to me) that non-printable characters aren't allowed or that there's some kind of encoding of the binary data into printable ascii that's required, but that encoding isn't defined. Section 4.2: Underscores aren't legal in domain names. Is there an existing ABNF production for a domain name that you could use instead (in case the set is expanded later?) You should also probably specify that this is in A-label form. > value =3D *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE "|" isn't a legal ABNF operator. Also, DQUOTE is included by VCHAR. For the record, how do quotes needed to delimit the data field of a CAA record presentation format interact with quotes in a parameter value? Is that worth allowing quotes in a value? (Again, you've mixed up "tag" and "property" and "value" throughout the document, making the prior sentence ambiguous.) By the way, how should issuers process malformed CAA records? Ignore them? Not issue? What's an "issuer-parameter"? Section 5: I debate the correctness of the last paragraph -- if Google had published CAA records, DigiNotar would still have issued those certs. Section 5.2: If the record is signed, bogus records had better be ignored. That needs to be added as a requirement in section 3.2 -- if DNSSEC is used, the record MUST not be bogus (ditto for denial of existence). Oh, I see that you say that in 5.2.1, but that probably is better placed in 3.2. I realize this section is ignoring DNSSEC, but it should be clear that this only applies for insecure domains.=20 Section 5.2.1: You say that lookup SHOULD be via authoritative servers, but then that you MUST NOT use cached data. Which is it? What additional anti-spoofing or anti-suppression controls are you referring to? Not looking for an exhaustive list, but some examples would be nice. Section 5.3: A CAA record can be malformed and yet secure. What are issuers supposed to do? Section 6.1/6.2: You don't label the first column. Which makes your direction to IANA about how to add to the registry ambiguous--especially in light of inconsistent wording. I hope this helps. --=20 Scott Schmit --HlL+5n6rz5pIUxbD Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNjAyMjMxMzUzWjAjBgkqhkiG9w0BCQQxFgQU1Qcm7yXj S7xf02dwxXbvBzwFkxcweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAm/JLywSc wY1J6Xdx2Z8aeoJIX/mU4cyDZ6iwcwD5X6hUG/lGCYZzTADZM2g5EjOxGLwugIHhPAfJM39f fkuY7uLuTZIBtEgURY9gvNNucSoK+U/nuulnY4hBrrH/7K+bDi5Uisl2UVXHtC/Iivxv8wKN HNuFeql4pDKdGg8XYmDZ8ZOB1zabc6xrFM4k+qE8+Tn7YtswSu7lzDA+lgsKcd0WGazEiMlE RGUBgU16a381kFPaom/XBpCVl3osSGGugdSIlDkEDfBZrUluCHwM5SLSnshU+hoTNipvhhHM ht70zXdaFOzBwYDM85E9W2K5i2IwomHidvfWMaaVq/xaJA== --HlL+5n6rz5pIUxbD-- From denis.pinkas@bull.net Mon Jun 4 00:39:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AEC21F876F for ; Mon, 4 Jun 2012 00:39:49 -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=[AWL=-0.262, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSD1BLHDZMGy for ; Mon, 4 Jun 2012 00:39:48 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4316521F8749 for ; Mon, 4 Jun 2012 00:39:48 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id CFDF218007; Mon, 4 Jun 2012 09:39:46 +0200 (CEST) In-Reply-To: <20120601151341.42A5E1A094@ld9781.wdf.sap.corp> References: <20120601151341.42A5E1A094@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: F779A0F0:AD41BC6F-C1257A13:0029D8BD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 4 Jun 2012 09:39:46 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 04/06/2012 09:39:46, Serialize complete at 04/06/2012 09:39:46 Content-Type: multipart/alternative; boundary="=_alternative 002A078CC1257A13_=" Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 07:39:49 -0000 Message en plusieurs parties au format MIME --=_alternative 002A078CC1257A13_= Content-Type: text/plain; charset="US-ASCII" Martin, I could say as well: After re-reading the existing specification (X.509 and PKIX) I have *NOT* found a rationale why an RP could reject an WXYZ response signed by a CA cert that does not have DigitalSignature asserted. So this is not a valid argument. Denis De : mrex@sap.com (Martin Rex) A : denis.pinkas@bull.net Cc : mrex@sap.com, "pkix@ietf.org" Date : 01/06/2012 17:13 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits denis.pinkas@bull.net wrote: > > Please refer to the previous emails and my presentation at the last PKIX > meeting: RFC 2560 is wrong and ambiguous. > > In a perfect world, we should have defined an OCSPsign key usage bit. We > failed to do it, or simply we did'nt. > > Do you believe we should define it now ? > If yes, what kind of migration path would you suggest ? > > If your answer to the first question is no, then the most reasonable > solution is to request the assertion of bit 0 > (data origin authentication) in the key usage extension when a CA directly > signs OCSP responses. After re-reading the existing specification (X.509 and PKIX) I have *NOT* found a rationale why an RP could reject an OCSP response signed by a CA cert that does not have DigitalSignature asserted. Retrofitting an additional requirement for issuing CAs about certs that should be permitted to sign OCSP responses in conjunction with an additional requiremnt for RPs to check, does not make any sense at this point in time for implementations based on rfc2560. -Martin --=_alternative 002A078CC1257A13_= Content-Type: text/html; charset="US-ASCII" Martin,

I could say as well: After re-reading the existing specification (X.509 and PKIX) I have
*NOT* found a rationale why an RP could reject an WXYZ response signed
by a CA cert that does not have DigitalSignature asserted.

So this is not a valid argument.

Denis



De :        mrex@sap.com (Martin Rex)
A :        denis.pinkas@bull.net
Cc :        mrex@sap.com, "pkix@ietf.org" <pkix@ietf.org>
Date :        01/06/2012 17:13
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits



denis.pinkas@bull.net wrote:
>
> Please refer to the previous emails and my presentation at the last PKIX
> meeting: RFC 2560 is wrong and ambiguous.
>
> In a perfect world, we should have defined an OCSPsign key usage bit. We
> failed to do it, or simply we did'nt.
>
> Do you believe we should define it now ?
> If yes, what kind of migration path would you suggest ?
>  
> If your answer to the first question is no, then the most reasonable
> solution is to request the assertion of  bit 0
> (data origin authentication) in the key usage extension when a CA directly
> signs OCSP responses.

After re-reading the existing specification (X.509 and PKIX) I have
*NOT* found a rationale why an RP could reject an OCSP response signed
by a CA cert that does not have DigitalSignature asserted.

Retrofitting an additional requirement for issuing CAs about certs
that should be permitted to sign OCSP responses in conjunction with
an additional requiremnt for RPs to check, does not make any sense
at this point in time for implementations based on rfc2560.


-Martin
--=_alternative 002A078CC1257A13_=-- From peter.sylvester@edelweb.fr Mon Jun 4 03:48:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAE921F87C4 for ; Mon, 4 Jun 2012 03:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJxm1cTWFlyt for ; Mon, 4 Jun 2012 03:48:20 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB721F87BF for ; Mon, 4 Jun 2012 03:48:19 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 96F547DB7 for ; Mon, 4 Jun 2012 12:48:17 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 24B897F18FA for ; Mon, 4 Jun 2012 12:35:00 +0200 (CEST) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 4C1D023636F for ; Mon, 4 Jun 2012 06:38:56 -0400 (EDT) Message-ID: <4FCC92E1.1090008@edelweb.fr> Date: Mon, 04 Jun 2012 12:50:09 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120601151341.42A5E1A094@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020400040207060700080500" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 10:48:21 -0000 This is a multi-part message in MIME format. --------------020400040207060700080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/04/2012 09:39 AM, denis.pinkas@bull.net wrote: > Martin, > > I could say as well: After re-reading the existing specification > (X.509 and PKIX) I have > *NOT* found a rationale why an RP could reject an WXYZ response signed > by a CA cert that does not have DigitalSignature asserted. > > So this is not a valid argument. OCSP is related to these documents and OCSP is revocation information to set digitalSignature is not required. Martin only confirms that nothing in these docs requires rejecting an OCSP response when digitalSignature is not set. If WXYZ == TSP you find ... > > Denis As already pointed out by Santosh, there is IMO no technical security reason to add a requirement to have digitalSignature on a CA cert in order to be able to sign an OCSP response. If ever some hypothetical rp doesn't like a CA cert without digitalSignature, the CA can even create an OCSP cert for its own key, it still matches the responderID. leaving alone the problem having responderId and the same subjectkeyinformation in two certs may create some problems elsewhere in certficate lookups. --------------020400040207060700080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/04/2012 09:39 AM, denis.pinkas@bull.net wrote:
Martin,

I could say as well: After re-reading the existing specification (X.509 and PKIX) I have
*NOT* found a rationale why an RP could reject an WXYZ response signed
by a CA cert that does not have DigitalSignature asserted.

So this is not a valid argument.
OCSP is related to these documents and OCSP is revocation
information to set digitalSignature is not required.
Martin only confirms that nothing in these docs requires
rejecting an OCSP response when digitalSignature is not
set. 

If WXYZ == TSP you find ...


Denis
As already pointed out by Santosh, there is IMO no
technical security reason to add a requirement to
have digitalSignature on a CA cert in order to be able
to sign an OCSP  response.

If ever some hypothetical rp doesn't like a CA cert
without digitalSignature, the CA can even create
an OCSP cert for its own key, it still matches the responderID.

leaving alone the problem having responderId and the
same subjectkeyinformation in two certs may
create some problems elsewhere in certficate lookups.


--------------020400040207060700080500-- From mrex@sap.com Mon Jun 4 04:08:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123CE21F8616 for ; Mon, 4 Jun 2012 04:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.191 X-Spam-Level: X-Spam-Status: No, score=-10.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jtkaFVXeFEv for ; Mon, 4 Jun 2012 04:08:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 01ECB21F8613 for ; Mon, 4 Jun 2012 04:08:42 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q54B8eu6021469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jun 2012 13:08:40 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Mon, 4 Jun 2012 13:08:40 +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: <20120604110840.4C6771A097@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Jun 2012 11:08:44 -0000 denis.pinkas@bull.net wrote: > > I could say as well: After re-reading the existing specification (X.509 > and PKIX) I have *NOT* found a rationale why an RP could reject an WXYZ > response signed by a CA cert that does not have DigitalSignature asserted. If the specification that standardizes WXYZ does not indiciate which particular KeyUsage attributes are required. Even more so, when that signed CA response falls into existing cagegories (cert issuance or cert revocation). The IMHO relevant snippets from X.509: X.509 08/2005 excerpts from 8.2.2.3 Key usage extension Setting a specific value of KeyUsage in a certificate does not in itself signal for an instance of communication that the communicating parties are acting in accordance with this setting, e.g., when signing a document. Definition of methods by which parties may signal their intent for a specific instance of communication (e.g., commitment to content for that specific instance) is outside the scope of this Directory Specification, but it is anticipated that multiple methods will exist. g) cRLSign: for verifying an authority's signature on CRLs. Since CRL signing is considered to be commitment to the content of the CRL by the CRL issuer, neither the digitalSignature bit nor the contentCommitment bit need be set in the certificate. If either (or both) is set, it does not affect the level of commitment the signer has endowed in the signed CRL; Application specifications should indicate which of the digitalSignature or contentCommitment bits are appropriate for their use. If a signing application has no knowledge of the signer's intent regarding commitment to content, the application shall sign and support that signing with a certificate that has the digitalSignature bit set in that certificate's keyUsage extension. plus the IMHO relevant snippet from rfc5280: http://tools.ietf.org/html/rfc5280#page-31 If the keyUsage extension is present, then the subject public key MUST NOT be used to verify signatures on certificates or CRLs unless the corresponding keyCertSign or cRLSign bit is set. If the subject public key is only to be used for verifying signatures on certificates and/or CRLs, then the digitalSignature and nonRepudiation bits SHOULD NOT be set. However, the digitalSignature and/or nonRepudiation bits MAY be set in addition to the keyCertSign and/or cRLSign bits if the subject public key is to be used to verify signatures on certificates and/or CRLs as well as other objects. Since OCSP (rfc2560) is completely silent on the KeyUsage attribute digitalSignature, only the general rules of X.509 and rfc5280 apply. And rfc5280 has a mere *MAY* for the presence of digitalSignature, which can *NOT* be interpreted as a "MUST be present" when RP's check those signatures. And the "Path validation algorithm" defined in rfc5280 Section 6.x requires only two checks on KeyUsage: 6.1.4 (n) keyCertSign (page 87) and 6.3.3 (f) cRLSign (page 94), so as far as rfc5280 is concerned, only this applies: the digitalSignature and/or nonRepudiation bits MAY be set in addition to the keyCertSign and/or cRLSign bits if the subject public key is to be used to verify signatures on certificates and/or CRLs as well as other objects. So an implementation of rfc5280 that fails because a CA cert that signed an OCSP response does not have digitalSignature is neither compliant with rfc2560+rfc5280 nor is it compliant with rfc2560+X.509-08/2005. -Martin From tmiller@mitre.org Mon Jun 4 06:09:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107F221F87BF for ; Mon, 4 Jun 2012 06:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4cns6lRakus for ; Mon, 4 Jun 2012 06:09:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 82BF421F86AD for ; Mon, 4 Jun 2012 06:09:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D94FE21B16C6; Mon, 4 Jun 2012 09:08:58 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B367721B11F0; Mon, 4 Jun 2012 09:08:58 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Mon, 4 Jun 2012 09:08:58 -0400 From: "Miller, Timothy J." To: Rob Stradling , Phillip Hallam-Baker Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAAALdGaAAACD4AD//64bAIAAfoMAgAD1nYCAAFnDgP//sZkAgACGVQCAAFaQgIADzmWA Date: Mon, 4 Jun 2012 13:08:57 +0000 Message-ID: In-Reply-To: <4FC93BA7.2020900@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.50.109] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F386E3FF1121F4E93701345E14E992B@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:09:02 -0000 On 6/1/12 5:01 PM, "Rob Stradling" wrote: >FWIW, Apple just voted in favour of allowing non-critical Name >Constraints (in the CABForum ballot currently being conducted on the >public CABForum list). I could be cynical and interpret this as Apple saying "We're not going to fix our code." Ah well. At least I can still beat Apple up when they fail on bridged trust test suites. -- T From steve.howard@certipath.com Thu May 31 08:46:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4295911E8128 for ; Thu, 31 May 2012 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi9+bbnjkrGi for ; Thu, 31 May 2012 08:46:02 -0700 (PDT) Received: from mail131.messagelabs.com (mail131.messagelabs.com [216.82.242.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0387911E811C for ; Thu, 31 May 2012 08:46:01 -0700 (PDT) X-Env-Sender: steve.howard@certipath.com X-Msg-Ref: server-11.tower-131.messagelabs.com!1338479158!24031636!1 X-Originating-IP: [216.166.12.72] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13162 invoked from network); 31 May 2012 15:45:59 -0000 Received: from out001.collaborationhost.net (HELO out001.collaborationhost.net) (216.166.12.72) by server-11.tower-131.messagelabs.com with RC4-SHA encrypted SMTP; 31 May 2012 15:45:59 -0000 Received: from AUSP01VMBX04.collaborationhost.net ([10.2.8.82]) by AUSP01MHUB50.collaborationhost.net ([10.2.10.3]) with mapi; Thu, 31 May 2012 10:45:57 -0500 From: Steve Howard To: IETF PKIX Date: Thu, 31 May 2012 10:47:11 -0500 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: AQF39hmXCiqgLXUqiOgOhbSZMn8uSwJqiPohAaLdI4YCJb0VFAEcL2GyAnUukDOXQHgMIA== Message-ID: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="----=_NextPart_000_0266_01CD3F23.1B26DF30"; protocol="application/x-pkcs7-signature"; micalg=SHA1 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Jun 2012 08:53:45 -0700 Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 20:59:29 -0000 ------=_NextPart_000_0266_01CD3F23.1B26DF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have been watching this thread with interest. So far, the discussion does not contemplate bridged infrastructure. Rather, the predominance of the discussion is driven by the PKI up to a WKR. As a bridge, CertiPath does apply name constraints, and we mark them critical, for our enterprise customers. We find this both useful and not to be an interoperability issue for our customers. Respectfully, Steve Stephen P. Howard | Vice President, Credentials | CertiPath LLC 2300 Corporate Park Drive, Ste 150, Herndon, VA 20171 PH +1.703.793.7879 | Direct +1.703.319.3171 | FAX +1.703.773.6262 Email Steve.Howard@CertiPath.com CertiPath: Enabling Trusted Communication www.certipath.com -----Original Message----- From: Wan-Teh Chang [mailto:wtc@google.com] Sent: Wednesday, May 30, 2012 7:31 PM To: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality RFC 2459 (a predecessor of RFC 5280) is 129 pages long. Isn't it possible that the reviewers of such a long document may have overlooked the full implications of "[The name constraints] extension MUST be critical"? Is the US DoD using the name constraints extension? Thanks, Wan-Teh ------=_NextPart_000_0266_01CD3F23.1B26DF30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIzxjCCA6Ew ggKJoAMCAQICECk2R6rjiqyGSiNW8sq3Ya8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCdXMx GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxMERkJDQTEWMBQGA1UEAxMNQ29tbW9u IFBvbGljeTAeFw0wNzEwMTUxNTU4MDBaFw0yNzEwMTUxNjA4MDBaME4xCzAJBgNVBAYTAnVzMRgw FgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBEZCQ0ExFjAUBgNVBAMTDUNvbW1vbiBQ b2xpY3kwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXjb0zJ+StW/t4vS9HR27HeOmT nKTeyRz9Lxs5OKxHF8B+dykAOwMfaA/NTaXud7gsYmsx9vpyCX0wKQZ853yjPYQYih2uLJKoH+he T42O6z8a+JwKZ52wZ03wLtAw3sOUsKDPLgo0f1QJ0za9pElXUnPpnf7kSHlGG1uNMuSlSGTzIg2S nQgVv2A8g/dHIiUirSlxt3fvF8mitpReyDCQpBRIXFZXC0FMBdQqTD+uEptZEXVwByJpLSzTMcyS fszNpH6UR6qcCQj2S69S6GpAkcVVvUCxyG1XhpUX5h9zvkcuPotMF7m5JRylUhc2CFnAQr4KK7RW UTwbVcmMkHfrAgMBAAGjezB5MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBQvWJfYqQWYpVYf+9mrde8CPDY0xzASBgkrBgEEAYI3FQEEBQIDAQABMCMGCSsGAQQBgjcV AgQWBBR2t2CW3RRWKax1hdNwY8G8R4YcizANBgkqhkiG9w0BAQUFAAOCAQEAYK7zSBZAcqYIiMm8 RywkS12gkXPtZXiQ8GeQeqW/Cq22KvmZZ9+DxXcfNAk4+X6eQeBIYP7iql2HiOqI/VxFsslq2n2k rbFPvxwNnx6awNUUczgrinhAbjD3YuHNmfxRaWdsEd24EKNo3ialVv02bDeYbPvufDxsa3A/90g3 CY8LQoGtRka4C4MG9Bs4oH9PzQvvg4mHlxyKMGfc/VShA34By4VMsQspw77sfOE/DwlSPC+nmkj+ N+kRBljhNkGKxLa/jt3OSrO8GsDN+hqZ0nGb+s+88sRUo4g1dswbLEZvDLTRw2F2knQR6kuAjRyJ EYvsW/8XyUj85+AGEeKEXjCCBi4wggUWoAMCAQICAgfUMA0GCSqGSIb3DQEBCwUAMFkxCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBEZQS0kxITAfBgNVBAMT GEZlZGVyYWwgQ29tbW9uIFBvbGljeSBDQTAeFw0xMTEyMjkxOTI4NThaFw0xNDEyMjkxOTI3NTRa MFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBEZQS0kx GjAYBgNVBAMTEUZlZGVyYWwgQnJpZGdlIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAuTNunuFVEpYm9m62hVimIWlLN0EkfScLkEB2UE5roUzkEnDzu4PyQHTb0xcpjiB5164p5D5j hvmMqsUEHpjXSKt8ouQAFLfiOlTobH0jYWU2SbEiqDbGe9k8ajlZCzLyljcmcb3GSt2xtcMeXhK7 SqpUTI06L8Rl8FZLQePyforve+UiMU9ZiGjbDVrckDlBd0+D+yvP7tVcD5mdkozDWIypxUFOxNFX 6NThBllK0dCq0gVE9lbuj0o9jsJBq+Xqeq6/tr426B6VhuuKjqAUB8hsHe7un/9kz5KA+TjqhnSj g+G8on8IuC+Wq2rrJ8WPmMu4zDPonxtaigxoLqTCYwIDAQABo4IDBTCCAwEwDwYDVR0TAQH/BAUw AwEB/zCCATMGA1UdIASCASowggEmMAwGCmCGSAFlAwIBAwIwDAYKYIZIAWUDAgEDDTAMBgpghkgB ZQMCAQMBMAwGCmCGSAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFl AwIBAxAwDAYKYIZIAWUDAgEDJDAMBgpghkgBZQMCAQMRMAwGCmCGSAFlAwIBAw4wDAYKYIZIAWUD AgEDDzAMBgpghkgBZQMCAQMSMAwGCmCGSAFlAwIBAxQwDAYKYIZIAWUDAgEDEzAMBgpghkgBZQMC AQMVMAwGCmCGSAFlAwIBAxcwDAYKYIZIAWUDAgEDFjAMBgpghkgBZQMCAQMYMAwGCmCGSAFlAwIB AxkwDAYKYIZIAWUDAgEDGjAMBgpghkgBZQMCAQMbME8GCCsGAQUFBwEBBEMwQTA/BggrBgEFBQcw AoYzaHR0cDovL2h0dHAuZnBraS5nb3YvZmNwY2EvY2FDZXJ0c0lzc3VlZFRvZmNwY2EucDdjMIGN BgNVHSEEgYUwgYIwGAYKYIZIAWUDAgEDBgYKYIZIAWUDAgEDAzAYBgpghkgBZQMCAQMHBgpghkgB ZQMCAQMMMBgGCmCGSAFlAwIBAxAGCmCGSAFlAwIBAwQwGAYKYIZIAWUDAgEDCAYKYIZIAWUDAgED JTAYBgpghkgBZQMCAQMkBgpghkgBZQMCAQMmME8GCCsGAQUFBwELBEMwQTA/BggrBgEFBQcwBYYz aHR0cDovL2h0dHAuZnBraS5nb3YvYnJpZGdlL2NhQ2VydHNJc3N1ZWRCeWZiY2EucDdjMA4GA1Ud DwEB/wQEAwIBBjAfBgNVHSMEGDAWgBStDHp1XOXzmMR5mA6sKP2X9OcC/DA1BgNVHR8ELjAsMCqg KKAmhiRodHRwOi8vaHR0cC5mcGtpLmdvdi9mY3BjYS9mY3BjYS5jcmwwHQYDVR0OBBYEFMSd/J1d Ol0Fer8CgezbSXAVx7JyMA0GCSqGSIb3DQEBCwUAA4IBAQBzhirzW/vi1cFHQbURqFARYxEIZ6Vk I7MwB2blvmH/NYl+XYfDdSXYY5mrjzBQqYdwrouP6iasO71HhKCGhWyJyrOlBM3rFra53rxssCeK 0MSwXKUnjMVd/+Po6+j7N3iCGUeYDyXcp7O9pDNWhs91x66aK6zKItWpOHn1xixLaXOkitefLBfc M5J30JVIe8JvPW9k60LV6x05LV1GIhU2nMsP/6kvemO1PsxFo98iFQbEkAd9/J0t6OESCTCcZoRh YbSYY9qDxqfg8afCuogqKVVSMgg7Kncw9HQGw9LYZOEIMzNlHgIs0V78bESo3ocZG28H12fNEWJw m8jP+fqkMIIGoTCCBYmgAwIBAgISESITndlnoPIJzsNRmvpM6wYLMA0GCSqGSIb3DQEBCwUAMFkx CzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpISUQgR2xvYmFsMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBB dXRob3JpdGllczETMBEGA1UEAxMKSElEUm9vdENBMTAeFw0xMTA1MTAwMDAwMDBaFw0yMTA1MTAw MDAwMDBaMFwxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpISUQgR2xvYmFsMSAwHgYDVQQLExdDZXJ0 aWZpY2F0ZSBBdXRob3JpdGllczEWMBQGA1UEAxMNSElEU2lnbmluZ0NBMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMQFfbsnk3M+1/gXTUNFvcnVHJxpUw1wYYC73ulK7EZTv5/j3t3V AgqDBMGu9iSgipq5tSak2LPSmcHHi49l/V9HeORNg1WxREeNnSJLOoTkFtR/davkOA/nGuLJMlAz rD62PuS4piR2ZPgK9cRvIS0+fRZJqfBbSLc1MXNtViiGwxU0XBb35qwfjuOkM474Tjp/i6SqlBUV wTnylWaE8fURMiek32Bhn+36YoFNwtkMVLA1WimLecr7tnu+FoqJ+2XQbH64VY9OiJLbOH5UaF2t nDrJz3sDzPxMGZpagEMgQcxXZ7+rBysY3aqeZjYAdUcffgm4H6oW4OJo774p78ECAwEAAaOCA14w ggNaMA4GA1UdDwEB/wQEAwIBxjASBgNVHRMBAf8ECDAGAQH/AgEAMIIBGQYDVR0gBIIBEDCCAQww QQYKKwYBBAGSXAIBAjAzMDEGCCsGAQUFBwIBFiVodHRwczovL3BpdmlzZXJ2aWNlLmhpZGdsb2Jh bC5jb20vQ1AvMEEGCisGAQQBklwCAQcwMzAxBggrBgEFBQcCARYlaHR0cHM6Ly9waXZpc2Vydmlj ZS5oaWRnbG9iYWwuY29tL0NQLzBBBgorBgEEAZJcAgEIMDMwMQYIKwYBBQUHAgEWJWh0dHBzOi8v cGl2aXNlcnZpY2UuaGlkZ2xvYmFsLmNvbS9DUC8wQQYKKwYBBAGSXAIBCTAzMDEGCCsGAQUFBwIB FiVodHRwczovL3BpdmlzZXJ2aWNlLmhpZGdsb2JhbC5jb20vQ1AvMIHjBgNVHR8EgdswgdgwgdWg gdKggc+GM2h0dHA6Ly9waXZpc2VydmljZS5oaWRnbG9iYWwuY29tL0NSTC9ISURSb290Q0ExLmNy bIaBl2xkYXA6Ly9waXZpc2VydmljZS5oaWRnbG9iYWwuY29tL0NOPUhJRFJvb3RDQTEsT1U9Q2Vy dGlmaWNhdGUlMjBBdXRob3JpdGllcyxPPUhJRCUyMEdsb2JhbCxDPVVTP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwgfAGCCsGAQUFBwEBBIHj MIHgMEMGCCsGAQUFBzAChjdodHRwOi8vcGl2aXNlcnZpY2UuaGlkZ2xvYmFsLmNvbS9DQWNlcnRz L0hJRFJvb3RDQTEucDdjMIGYBggrBgEFBQcwAoaBi2xkYXA6Ly9waXZpc2VydmljZS5oaWRnbG9i YWwuY29tL0NOPUhJRFJvb3RDQTEsT1U9Q2VydGlmaWNhdGUlMjBBdXRob3JpdGllcyxPPUhJRCUy MEdsb2JhbCxDPVVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0Ew HQYDVR0OBBYEFEdASUEGI/KfPCCO0OlSphLcHLxXMB8GA1UdIwQYMBaAFCGAgKYmAsU4Audh7XoH 3MnyY7X4MA0GCSqGSIb3DQEBCwUAA4IBAQARe9ZXu9N9t0/8bfEX0Eord5eP3RzPhQKJVzy1SQ6e bartEQxlv+V268SnT292T9XULrO4cC7B6ZWeHEPZCliRnFDxo6u0+j6ZvdbBEYShGWXlBpfv9T5m WwMzSyfynh9+NAy5IO28WsOj9EWw1OW7jb1sgpnGYVY4xB3hhOzbta90jW9lcZldw+uXXOU7XbPc hy0Pg1zazvbwjYwOC6c2+WBTEw0Zpq7wDL9d0FDaJF98a3Y3/l5lm0IQGStFc1aJP/t93zzCpBT6 w+AqOJ7Zd2IFWwI+HkW8gP20Y1X+62W35cAQcBxWSPdavRtuocO0A7sznIdA2QSyF1GyEq/uMIIG pTCCBY2gAwIBAgISESEsKpo6MEbLlXiMJIl9RL8OMA0GCSqGSIb3DQEBCwUAMFwxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpISUQgR2xvYmFsMSAwHgYDVQQLExdDZXJ0aWZpY2F0ZSBBdXRob3JpdGll czEWMBQGA1UEAxMNSElEU2lnbmluZ0NBMTAeFw0xMTA5MzAxNjAxMzZaFw0xNDA5MzAxNjAxMzZa MIGJMQswCQYDVQQGEwJVUzETMBEGA1UEChMKSElEIEdsb2JhbDEUMBIGA1UECxMLU3Vic2NyaWJl cnMxEjAQBgNVBAsTCUNlcnRpUGF0aDEaMBgGA1UEAxMRU3RlcGhlbiBQLiBIb3dhcmQxHzAdBgoJ kiaJk/IsZAEBEw8xMDAwMDAwMDAwMDAwNjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDNpqhVTmc9cVF4lGJOVe+a8hiexdC2cWZgAsE3JRCE9H4BRnyfVuN1nygqbDlzPJEy3gvlPGQM 7FcIXAvxGKeFR+L3znBo3MqeeHxiOv0i4as10VkP1q5jEb/TlqUxPPay6nIveiU1FaW9i0KBQfiC DbsBXS3bZZUwbzGQB928Ba+ywv3602Ws8qxQh3dg8cxQpXObio7iW4stHwzLvHB5bdzNQk4+8yS2 ar1Kn1I5vf5nwLmEOWN9WDpGsNoSZfNE+0VogqvmuUtmZC3YGFcOk+egQgE/Tg9x8VIwQJfc4Zy6 Uqe9rNFbEPiJcHDW0PTzsIWkNVv+moL2ZTan2H01AgMBAAGjggMxMIIDLTAOBgNVHQ8BAf8EBAMC BDAwgZEGA1UdIASBiTCBhjBBBgorBgEEAZJcAgECMDMwMQYIKwYBBQUHAgEWJWh0dHBzOi8vcGl2 aXNlcnZpY2UuaGlkZ2xvYmFsLmNvbS9DUC8wQQYKKwYBBAGSXAIBBzAzMDEGCCsGAQUFBwIBFiVo dHRwczovL3BpdmlzZXJ2aWNlLmhpZGdsb2JhbC5jb20vQ1AvMCUGA1UdEQQeMByBGnN0ZXZlLmhv d2FyZEBjZXJ0aXBhdGguY29tMIHvBgNVHR8EgecwgeQwPKA6oDiGNmh0dHA6Ly9waXZpc2Vydmlj ZS5oaWRnbG9iYWwuY29tL0NSTC9ISURTaWduaW5nQ0ExLmNybDCBo6CBoKCBnYaBmmxkYXA6Ly9w aXZpc2VydmljZS5oaWRnbG9iYWwuY29tL0NOPUhJRFNpZ25pbmdDQTEsT1U9Q2VydGlmaWNhdGUl MjBBdXRob3JpdGllcyxPPUhJRCUyMEdsb2JhbCxDPVVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxp c3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9cGtpQ0EwggEsBggrBgEFBQcBAQSCAR4wggEaMDIG CCsGAQUFBzABhiZodHRwOi8vcGl2aXNlcnZpY2UuaGlkZ2xvYmFsLmNvbS9PQ1NQLzBGBggrBgEF BQcwAoY6aHR0cDovL3BpdmlzZXJ2aWNlLmhpZGdsb2JhbC5jb20vQ0FjZXJ0cy9ISURTaWduaW5n Q0ExLnA3YzCBmwYIKwYBBQUHMAKGgY5sZGFwOi8vcGl2aXNlcnZpY2UuaGlkZ2xvYmFsLmNvbS9D Tj1ISURTaWduaW5nQ0ExLE9VPUNlcnRpZmljYXRlJTIwQXV0aG9yaXRpZXMsTz1ISUQlMjBHbG9i YWwsQz1VUz9jQUNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPXBraUNBMB0GA1Ud DgQWBBS19hp78ZrorqE6tlnRBc3tCmx/1TAfBgNVHSMEGDAWgBRHQElBBiPynzwgjtDpUqYS3By8 VzANBgkqhkiG9w0BAQsFAAOCAQEADk5l4rpsn6Xogob7A8uXcIdAtuCq/YnnCkIyndA1/YMUK4Cf RZqTiECouXdi5OQF3QKMr03EdZ2jdljGVxlt4N863g8xoCiShtolx2CkIKrwHR3Kvp0DdsMYuaWJ CcPAWKDxkRraL7yy5vxZp6XgSikj5Z6WtrcJ6hVmyrCaHHxaNJuoz+iLyCrJPH1KuvUkpNvEFnjh nQLV9BbH9J+r15XAKoPulm16prmgmkbdWFjEQau/TF+5Mv47esMwhOGGfdwdL31Sus+kdC6On1RQ ere6ePaRiOeuLlWdoi+1dGyR7wpf8fuJpMHyERXZHphzsar6hE6uKo50jNYbJ5DzizCCBqUwggWN oAMCAQICEhEhZ+6+hrRiwsdGg/3TOhkTYzANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzET MBEGA1UEChMKSElEIEdsb2JhbDEgMB4GA1UECxMXQ2VydGlmaWNhdGUgQXV0aG9yaXRpZXMxFjAU BgNVBAMTDUhJRFNpZ25pbmdDQTEwHhcNMTEwOTMwMTYwNDE1WhcNMTQwOTMwMTYwNDE1WjCBiTEL MAkGA1UEBhMCVVMxEzARBgNVBAoTCkhJRCBHbG9iYWwxFDASBgNVBAsTC1N1YnNjcmliZXJzMRIw EAYDVQQLEwlDZXJ0aVBhdGgxGjAYBgNVBAMTEVN0ZXBoZW4gUC4gSG93YXJkMR8wHQYKCZImiZPy LGQBARMPMTAwMDAwMDAwMDAwMDYzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxP1H jmR+9ELnPetM5IWMN35V6tz3zo5M5tx6x/RTI4IdxX4jGCC5rjtT+OxwDC6NjNJzeSgfXIpWY/Tm Khgj25MB68oQJhxx3aluEX/FN7XFQiL7wZ3hSfC84uTmJQUOrgu/zvaHyTGjFvg4+q4XW19o9hiJ 2FgwUUHgdNzpWJWSSkUctHX6UGB3NsLXITbCRiTEYLYq2zdCKhTXI6ot7oe1BxmjPiV/q10NGnve 943Xq73gPmiYQA5GFl8JWJlYeNLkCBqpm7X4Q0XepxB+8aNYXTMjr2GZog/VanmnNXGmMzKnJyQ8 9N7GAtQhU3monrQLOWkfnXcx2yX51TpFSwIDAQABo4IDMTCCAy0wDgYDVR0PAQH/BAQDAgbAMIGR BgNVHSAEgYkwgYYwQQYKKwYBBAGSXAIBAjAzMDEGCCsGAQUFBwIBFiVodHRwczovL3BpdmlzZXJ2 aWNlLmhpZGdsb2JhbC5jb20vQ1AvMEEGCisGAQQBklwCAQcwMzAxBggrBgEFBQcCARYlaHR0cHM6 Ly9waXZpc2VydmljZS5oaWRnbG9iYWwuY29tL0NQLzAlBgNVHREEHjAcgRpzdGV2ZS5ob3dhcmRA Y2VydGlwYXRoLmNvbTCB7wYDVR0fBIHnMIHkMDygOqA4hjZodHRwOi8vcGl2aXNlcnZpY2UuaGlk Z2xvYmFsLmNvbS9DUkwvSElEU2lnbmluZ0NBMS5jcmwwgaOggaCggZ2GgZpsZGFwOi8vcGl2aXNl cnZpY2UuaGlkZ2xvYmFsLmNvbS9DTj1ISURTaWduaW5nQ0ExLE9VPUNlcnRpZmljYXRlJTIwQXV0 aG9yaXRpZXMsTz1ISUQlMjBHbG9iYWwsQz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2Jp bmFyeT9iYXNlP29iamVjdGNsYXNzPXBraUNBMIIBLAYIKwYBBQUHAQEEggEeMIIBGjAyBggrBgEF BQcwAYYmaHR0cDovL3BpdmlzZXJ2aWNlLmhpZGdsb2JhbC5jb20vT0NTUC8wRgYIKwYBBQUHMAKG Omh0dHA6Ly9waXZpc2VydmljZS5oaWRnbG9iYWwuY29tL0NBY2VydHMvSElEU2lnbmluZ0NBMS5w N2MwgZsGCCsGAQUFBzAChoGObGRhcDovL3BpdmlzZXJ2aWNlLmhpZGdsb2JhbC5jb20vQ049SElE U2lnbmluZ0NBMSxPVT1DZXJ0aWZpY2F0ZSUyMEF1dGhvcml0aWVzLE89SElEJTIwR2xvYmFsLEM9 VVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1wa2lDQTAdBgNVHQ4EFgQU ttAkveg/GmQPiaH4iqyDnxh2kQEwHwYDVR0jBBgwFoAUR0BJQQYj8p88II7Q6VKmEtwcvFcwDQYJ KoZIhvcNAQELBQADggEBAFM2YxZMrCNuRE7w9CWCGe1gGB5T2HKri8DzWqrWXbAXNSLhxSf8TIIM Uev1IWRcNRMKmPR+LlobGwKzeks6tt6F6+9UsMXmdEzjgllASstO5otM+Z+RPmT59ciYVo4LAVY8 klHLlCtatlY5OpLQ4JMAbXEdcGOci9e0E18t5FZJid+z0HaWIhQvvg4yDNZynQsA64ymVX6l1Q2b RXr44Zfmu8QC7VflJ6dSn7dECvsuCw2//70hYyuumWqXEs7DrQBSKawRthFSW4NsU868QPdmeHOk d4O/i3k7Y2rurAgnvQ4KgYac/OPXLy3kg8GBQySeJsrOhFVVMgStmN2h9WYwggbOMIIFtqADAgEC AhB4yJfoEegGRChwPJSzPScnMA0GCSqGSIb3DQEBCwUAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQK Ew1DZXJ0aVBhdGggTExDMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMSEwHwYD VQQDExhDZXJ0aVBhdGggQnJpZGdlIENBIC0gRzIwHhcNMTEwNjMwMDAwMDAwWhcNMTIwNjI5MjM1 OTU5WjBZMQswCQYDVQQGEwJVUzETMBEGA1UEChMKSElEIEdsb2JhbDEgMB4GA1UECxMXQ2VydGlm aWNhdGUgQXV0aG9yaXRpZXMxEzARBgNVBAMTCkhJRFJvb3RDQTEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMO81TMQsdznRXEGdMlyN3uPa2tXWZUG6iCKLdFBypFOpdVgsFDCOCdY8j EPcWKA8bPZjSG+qU89z+daoOH2XGc6R32rTFBVeE9JINJhteBappUCzB7ydcnln9hwoz21Y+ZEqO P7GnjxPeTDmiDq7RTZHguMdMnNN5PAMkoHsYhUIEFgSeb8q/+5FezuZdY9ERhl4kZi43ZOMUkmNm b9vzpL6YC80LN0IQu3h+JiJmg4pjF6zJ/RtawMkNuTii/gQ6Pq755pjzpoAyEdRBLvgmSgY0gYT3 pnnOx6OFoQixgGc2iYBoNN7nBw23O5/WxxR/SNX8b5XDp8+XpNfxD/fbAgMBAAGjggN9MIIDeTAS BgNVHRMBAf8ECDAGAQH/AgEBMEkGA1UdIARCMEAwDgYMKwYBBAGBu1MBAQECMA4GDCsGAQQBgbtT AQEBBzAOBgwrBgEEAYG7UwEBAQgwDgYMKwYBBAGBu1MBAQEJMIIBGwYIKwYBBQUHAQEEggENMIIB CTBGBggrBgEFBQcwAoY6aHR0cDovL2NlcnRpcGF0aC1haWEudmVyaXNpZ24uY29tL0NlcnRpUGF0 aEJyaWRnZUNBLUcyLnA3YzCBvgYIKwYBBQUHMAKGgbFsZGFwOi8vY2VydGlwYXRoLWFpYS1sZGFw LnZlcmlzaWduLmNvbS9DTj1DZXJ0aVBhdGglMjBCcmlkZ2UlMjBDQSUyMC0lMjBHMixPVT1DZXJ0 aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsTz1DZXJ0aVBhdGglMjBMTEMsQz1VUz9jQUNlcnRpZmlj YXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwgfQGA1UdHwSB7DCB6TCB5qCB 46CB4IY6aHR0cDovL2NlcnRpcGF0aC1jcmwudmVyaXNpZ24uY29tL0NlcnRpUGF0aEJyaWRnZUNB LUcyLmNybIaBoWxkYXA6Ly9jZXJ0aXBhdGgtY3JsLWxkYXAudmVyaXNpZ24uY29tL0NOPUNlcnRp UGF0aCUyMEJyaWRnZSUyMENBJTIwLSUyMEcyLE9VPUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGll cyxPPUNlcnRpUGF0aCUyMExMQyxDPVVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5 MA4GA1UdDwEB/wQEAwIBxjAKBgNVHTYEAwIBADAMBgNVHSQEBTADgQEAMIGXBgNVHSEEgY8wgYww GgYMKwYBBAGBu1MBAQECBgorBgEEAZJcAgECMBoGDCsGAQQBgbtTAQEBAgYKKwYBBAGSXAIBBzAa BgwrBgEEAYG7UwEBAQcGCisGAQQBklwCAQcwGgYMKwYBBAGBu1MBAQEIBgorBgEEAZJcAgEIMBoG DCsGAQQBgbtTAQEBCQYKKwYBBAGSXAIBCTAdBgNVHQ4EFgQUIYCApiYCxTgC52HtegfcyfJjtfgw HwYDVR0jBBgwFoAU0MKMEzczdkqRqDzh6Lf9opzR3RQwDQYJKoZIhvcNAQELBQADggEBAGxlNlov TbFO4PwqWI8kOfQvToqIWyqRhbWELiOCItoGBo4NI8M+5Xiy5VHfiJRXDcnUyu2DezgrrM54TwXf KDNjbeKas1qmGZmwlLItoKZgyIw+BSn9Sz616XS7i2tji1/yG48bR9tONMsFzY/unR4jk3/s0h3N b8E5EMcvhU0NUVOD9YL50zjkkkHdxfTCe3Juwrjrrdnz2uwJ5snhD3swgRh7XOW3R1CZyxFziJpO HW9JaaO4nUAIBuFvz6H1R6NW0SSFGarjYRH6bed04sLUlZMXx/F7km7lxb2MU+aKfNO+VlRwz9xv AqCwVxHglxriXx27YFG0kL0/3bYMukgwggdeMIIGRqADAgECAgpILZNeAAEAAAB+MA0GCSqGSIb3 DQEBBQUAME4xCzAJBgNVBAYTAnVzMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsT BEZCQ0ExFjAUBgNVBAMTDUNvbW1vbiBQb2xpY3kwHhcNMTEwMjExMTYzNzQwWhcNMTMxMjMxMTY0 NzQwWjBZMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQ0wCwYDVQQLEwRG UEtJMSEwHwYDVQQDExhGZWRlcmFsIENvbW1vbiBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDYdfs1FjRaQb9ar1wwBBQcrXhEteom6nVhx802efh82L0pUWZZIeN5q9R4 vrAtsKHVsjUWI9DMHr4O6Kvcw8nWEtencmgYMbgXIrI+froIbcb90VgsaaAD8Cqj9j8hJT3ftzLF jiezI6XgUrNdlumwuMXFn7vFoG6CQLvFJwU2SdYmJ2kMNI/PJ3oqCqNBX40dA4aDFeBVwcWYLJ7s GnLcSME++YTShILBG8N0Nre5xzYyevgyttA2riIYMYxQcyGe/oM7MIgk4+nBft7tmMcfkhCKn1ti L52kvNWFbzr9yVOnIEuq2yCrIU4dDU7mmIXlqxFHXZ0/xCPA4xQGbv6dAgMBAAGjggQxMIIELTAP BgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUrQx6dVzl85jEeZgOrCj9l/Tn AvwwHwYDVR0jBBgwFoAUL1iX2KkFmKVWH/vZq3XvAjw2NMcwgbkGA1UdHwSBsTCBrjCBq6CBqKCB pYY1aHR0cDovL2Zwa2lhLmdzYS5nb3YvQ29tbW9uUG9saWN5L0NvbW1vblBvbGljeSgxKS5jcmyG bGxkYXA6Ly9mcGtpYS5nc2EuZ292L2NuPUNvbW1vbiUyMFBvbGljeSgxKSxvdT1GQkNBLG89VS5T LiUyMEdvdmVybm1lbnQsYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCB3AYI KwYBBQUHAQEEgc8wgcwwQgYIKwYBBQUHMAKGNmh0dHA6Ly9mcGtpYS5nc2EuZ292L0NvbW1vblBv bGljeS9Db21tb25Qb2xpY3lSb290LnA3YzCBhQYIKwYBBQUHMAKGeWxkYXA6Ly9mcGtpYS5nc2Eu Z292L2NuPUNvbW1vbiUyMFBvbGljeSxvdT1GQkNBLG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9j QUNlcnRpZmljYXRlO2JpbmFyeSxjcm9zc0NlcnRpZmljYXRlUGFpcjtiaW5hcnkwHQYJKwYBBAGC NxQCBBAeDgBDAHIAbwBzAHMAQwBBMIIBJQYDVR0gBIIBHDCCARgwDAYKYIZIAWUDAgEDBjAMBgpg hkgBZQMCAQMHMAwGCmCGSAFlAwIBAwgwDAYKYIZIAWUDAgEDDTAMBgpghkgBZQMCAQMQMAwGCmCG SAFlAwIBAxEwDAYKYIZIAWUDAgEDATAMBgpghkgBZQMCAQMCMAwGCmCGSAFlAwIBAw4wDAYKYIZI AWUDAgEDDzAMBgpghkgBZQMCAQMSMAwGCmCGSAFlAwIBAxQwDAYKYIZIAWUDAgEDEzAMBgpghkgB ZQMCAQMVMAwGCmCGSAFlAwIBAxcwDAYKYIZIAWUDAgEDFjAMBgpghkgBZQMCAQMYMAwGCmCGSAFl AwIBAxkwDAYKYIZIAWUDAgEDGjAMBgpghkgBZQMCAQMbMIHpBggrBgEFBQcBCwSB3DCB2TCBlQYI KwYBBQUHMAWGgYhsZGFwOi8vbGRhcC5mcGtpLmdvdi9jbj1GZWRlcmFsJTIwQ29tbW9uJTIwUG9s aWN5JTIwQ0Esb3U9RlBLSSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y0FDZXJ0aWZpY2F0ZTti aW5hcnksY3Jvc3NDZXJ0aWZpY2F0ZVBhaXI7YmluYXJ5MD8GCCsGAQUFBzAFhjNodHRwOi8vaHR0 cC5mcGtpLmdvdi9mY3BjYS9jYUNlcnRzSXNzdWVkQnlmY3BjYS5wN2MwDQYJKoZIhvcNAQEFBQAD ggEBABTRblqwFmoyGZKgg4HfLVdBzgq6xH8yv1lLOYf1R1szTmyr/Z/lUwtCuinH2Q/mjXmm91VR jKVv6WQJBfOBjTh/2l5n54FjmClXW2/VWHpDBOjTVGuCudES5i+eCD4A5yGbYkExyWtCltZAKvx9 6KP8TbLxDjOtif8+QrlBCbpFPvIHfBuqbWWJMOQANJcq+kCpLqltsSxesNx/6kPCA+0Iaobue6o7 nSerOWrxL8HBrFfabAzNHRPYOL7ZwB1kKvCl7C9sgZNkye1yh2xCvyJ4zN6oXrjAs4NTBs/AkbzH UmrikHV3eOphb82EZme/jXpsEYirq/lnSnHydF5Hf/YwggfAMIIGqKADAgECAgIDjjANBgkqhkiG 9w0BAQsFADBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQ0wCwYDVQQL EwRGUEtJMRowGAYDVQQDExFGZWRlcmFsIEJyaWRnZSBDQTAeFw0xMTAzMDkyMzAwNTBaFw0xNDAz MDkyMTU1NDVaMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1DZXJ0aVBhdGggTExDMSIwIAYDVQQL ExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMSEwHwYDVQQDExhDZXJ0aVBhdGggQnJpZGdlIENB IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDS1uJF4kar8AYSXzfbs9dhQPj9 g9+DD8Tre0xl5Y5tqZSdgi872h/P8prDHUlnSQUtTPBZsLzS9cNwOmbs5LCYz4pALvJGN3XKd5q5 JPXgjzkQwMBrX7F8GcrC4rhGg1qWw3Rzmh5yOqllNDejiPoTV+fBIw6SBgtVkHYaNbRzkz3OR3+f 4TqTP9vb/8K+5Mko7Gfu57L5JuazYbiTcz7C7IM1WiefwVcjqZWctuBSjPGONzI0eKLGZvmtntM5 4qsOv673I3BmGm2Gs52X0BtRl6Mn9lXmvggoKYFIZVWn4JMBLPIs5fKyKbwc14hQIBULhiLbqMvd jyWw7ON9HwP3AgMBAAGjggSEMIIEgDAPBgNVHRMBAf8EBTADAQH/MHkGA1UdIARyMHAwDAYKYIZI AWUDAgEDAzAMBgpghkgBZQMCAQMMMAwGCmCGSAFlAwIBAw4wDAYKYIZIAWUDAgEDDzAMBgpghkgB ZQMCAQMSMAwGCmCGSAFlAwIBAxMwDAYKYIZIAWUDAgEDFDAMBgpghkgBZQMCAQMIMIHfBggrBgEF BQcBAQSB0jCBzzA/BggrBgEFBQcwAoYzaHR0cDovL2h0dHAuZnBraS5nb3YvYnJpZGdlL2NhQ2Vy dHNJc3N1ZWRUb2ZiY2EucDdjMIGLBggrBgEFBQcwAoZ/bGRhcDovL2xkYXAuZnBraS5nb3YvY249 RmVkZXJhbCUyMEJyaWRnZSUyMENBLG91PUZQS0ksbz1VLlMuJTIwR292ZXJubWVudCxjPVVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5LGNyb3NzQ2VydGlmaWNhdGVQYWlyO2JpbmFyeTCCAUEGA1UdIQSC ATgwggE0MBoGCmCGSAFlAwIBAwMGDCsGAQQBgbtTAQEBATAaBgpghkgBZQMCAQMMBgwrBgEEAYG7 UwEBAQIwGgYKYIZIAWUDAgEDDAYMKwYBBAGBu1MBAQEDMBoGCmCGSAFlAwIBAw4GDCsGAQQBgbtT AQEBBDAaBgpghkgBZQMCAQMPBgwrBgEEAYG7UwEBAQUwGgYKYIZIAWUDAgEDDAYMKwYBBAGBu1MB AQEHMBoGCmCGSAFlAwIBAxIGDCsGAQQBgbtTAQEBBzAaBgpghkgBZQMCAQMTBgwrBgEEAYG7UwEB AQgwGgYKYIZIAWUDAgEDFAYMKwYBBAGBu1MBAQEJMBoGCmCGSAFlAwIBAwgGDCsGAQQBgbtTAQEB CTAaBgpghkgBZQMCAQMIBgwrBgEEAYG7UwEBAQEwcQYDVR0eAQH/BGcwZaFjMCukKTAnMQswCQYD VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MBmkFzAVMRMwEQYKCZImiZPyLGQBGRYD bWlsMBmkFzAVMRMwEQYKCZImiZPyLGQBGRYDZ292MFYGCCsGAQUFBwELBEowSDBGBggrBgEFBQcw BYY6aHR0cDovL2NlcnRpcGF0aC1haWEudmVyaXNpZ24uY29tL0NlcnRpUGF0aEJyaWRnZUNBLUcy LnA3YzAOBgNVHQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUxJ38nV06XQV6vwKB7NtJcBXHsnIwga8G A1UdHwSBpzCBpDAqoCigJoYkaHR0cDovL2h0dHAuZnBraS5nb3YvYnJpZGdlL2ZiY2EuY3JsMHag dKByhnBsZGFwOi8vbGRhcC5mcGtpLmdvdi9jbiUzZEZlZGVyYWwlMjBCcmlkZ2UlMjBDQSxvdSUz ZEZQS0ksbyUzZFUuUy4lMjBHb3Zlcm5tZW50LGMlM2RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0MB0GA1UdDgQWBBTQwowTNzN2SpGoPOHot/2inNHdFDANBgkqhkiG9w0BAQsFAAOCAQEAfh9x KHbNW3gc+nvjt6oZN+O5njvnFGZc5zOE8Ke1teQBICpZ7Ssgwc4nzQKT1t9ax+vNguGXvtveNpFs sXlod45hlKRLsJsMm2HF7rWKBsNPpNBzRT/zJT6Cwd06+tx1UEjqqIVJnh910c9tY5+jnhj6c36B SNY2/yemqvZT0gqM7voa4VVqPQDZeF2oks1Z34RU/nYdIKGxXVgcDlELInMskNWgIT5vRr/9q5OW NOnYs8S9TvAflAgKDCVBWSO/t4aRf3GPNLSlgGKE/griNenIFS7IUMlTtweh4TutV2XAzKlXe4+V jzF/qlYmvO/oYmhTcWlakolM8l4i1ZyNejGCA14wggNaAgEBMHIwXDELMAkGA1UEBhMCVVMxEzAR BgNVBAoTCkhJRCBHbG9iYWwxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVzMRYwFAYD VQQDEw1ISURTaWduaW5nQ0ExAhIRIWfuvoa0YsLHRoP90zoZE2MwCQYFKw4DAhoFAKCCAcEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNTMxMTU0NzA3WjAjBgkq hkiG9w0BCQQxFgQUCQPiOqbNEgYmL+zjN7JQjiRthkUwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYI KoZIhvcNAgUwgYEGCSsGAQQBgjcQBDF0MHIwXDELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkhJRCBH bG9iYWwxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVzMRYwFAYDVQQDEw1ISURTaWdu aW5nQ0ExAhIRISwqmjowRsuVeIwkiX1Evw4wgYMGCyqGSIb3DQEJEAILMXSgcjBcMQswCQYDVQQG EwJVUzETMBEGA1UEChMKSElEIEdsb2JhbDEgMB4GA1UECxMXQ2VydGlmaWNhdGUgQXV0aG9yaXRp ZXMxFjAUBgNVBAMTDUhJRFNpZ25pbmdDQTECEhEhLCqaOjBGy5V4jCSJfUS/DjANBgkqhkiG9w0B AQEFAASCAQC0wsSopqPXlbrkVl0BYPjHIDfADEI2wws7cYl3Z2zRbp/+5Ww5hDE6Y43K3/UTJV1p jjdDSyU771plRj1WBIZMed33C00XmcH5QsX3GwJDoFBlI4/8IImuEcIsn0uXKSiq0cqfJbEkD7pC /LoZnG79/8LD47bJ6+NFwZZgi9DPv3aa1zbt2XTFp8U57vjMUnDWlW8y+Rnh2VjprCALaN5p0FPq T7+wSi5ebImNy/gX23Ij5U/fuxF4v5hh+MYHeuy5DGS6YUAF6FTrG+IcLpI7oUayd9u8tTkykInF YQXcOmagGq0KL0OOA2MjNUm3CcYyyhibn+orDexeILjgUonzAAAAAAAA ------=_NextPart_000_0266_01CD3F23.1B26DF30-- From kent@bbn.com Mon Jun 4 12:34:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8C11E80E8 for ; Mon, 4 Jun 2012 12:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.338 X-Spam-Level: X-Spam-Status: No, score=-106.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7OHA23g4npi for ; Mon, 4 Jun 2012 12:34:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 042B611E80CD for ; Mon, 4 Jun 2012 12:34:25 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49157) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sbd25-000IHh-UL; Mon, 04 Jun 2012 15:33:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4FC6AEDA.4010709@cs.tcd.ie> <8762bbaa15.fsf@windlord.stanford.edu> Date: Mon, 4 Jun 2012 15:06:36 -0400 To: denis.pinkas@bull.net From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-873284041==_ma============" Cc: pkix , Russ Allbery , Jim Schaad Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 19:34:25 -0000 --============_-873284041==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:24 AM +0200 6/1/12, denis.pinkas@bull.net wrote: >First of all, thank you for both of you for your fast response. > >I am not arguing there is an RFC 5742 conflict with this document. > >Since you said that is an attempt to document an existing deployed >protocol, we cannot change it. > >Since you said that designing a better protocol is an expected >follow-on work, I raise the question to both the editors and the WG >chairs >whether the document should be on the experimental track rather than >on the informational track. Necause this is documenting an extant protocol, informational seems more appropriate than experimental. Steve --============_-873284041==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about R
At 9:24 AM +0200 6/1/12, denis.pinkas@bull.net wrote:
First of all, thank you for both of you for your fast response.

I am not arguing there is an RFC 5742 conflict with this document.

Since you said that is an attempt to document an existing deployed protocol, we cannot change it.

Since you said that designing a better protocol is an expected follow-on work, I raise the question to both the editors and the WG chairs
whether the document should be on the experimental track rather than on the informational track.

Necause this is documenting an extant protocol, informational seems more
appropriate than experimental.

Steve
--============_-873284041==_ma============-- From kent@bbn.com Mon Jun 4 13:35:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9B11E80A6 for ; Mon, 4 Jun 2012 13:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f5tZspAE3-S for ; Mon, 4 Jun 2012 13:35:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C25B221F87C5 for ; Mon, 4 Jun 2012 13:35:22 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49167) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sbdz7-000KMn-AA; Mon, 04 Jun 2012 16:34:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4FC8AD99.3030705@comodo.com> References: <20120601095014.3FD7A1A094@ld9781.wdf.sap.corp> <4FC8AD99.3030705@comodo.com> Date: Mon, 4 Jun 2012 16:05:35 -0400 To: Rob Stradling From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:35:24 -0000 At 12:55 PM +0100 6/1/12, Rob Stradling wrote: >On 01/06/12 10:50, Martin Rex wrote: >>Rob Stradling wrote: >>> >>>RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign >>>bit is asserted when the subject public key is used for verifying a >>>signature on revocation information (e.g., a CRL)." >> >>Hmmmm. I think you have a point here. This definition still applies >>to rfc3280 and rfc5280, actually: > >If we can say that OCSP Responses are a form of "certificate >revocation list", then yes, the definition still applies. OCSP responses are not a form of CRL. They are a form of cert revocation status info. Steve From pritikin@cisco.com Mon Jun 4 15:09:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CB421F86DF for ; Mon, 4 Jun 2012 15:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXB-YOkq4GPy for ; Mon, 4 Jun 2012 15:09:19 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 510B421F86DB for ; Mon, 4 Jun 2012 15:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=7661; q=dns/txt; s=iport; t=1338847759; x=1340057359; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=054nCh+HTG4LbjJs2wtScJzEfMoahvIQm1r08JCyNlo=; b=DJ75o4nIT99291C/aODaxQXQ1sFCK+4BiAbo99PsJMx0BR91r7+EDWr0 ZNeg6hLbZQZBHRuva4nmHjhjPFhZOpJTNSABemy/4SEc+LF7xGLRSLn9+ sygtIvdbH2IPrwl/mj9wGBgF0C+Z9X1K9xVz4zzh94+2De63FfuQ5NE41 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPAwzU+rRDoG/2dsb2JhbAA7CbQrgQeCGAEBAQMBAQEBDwEnNAsFBwQLEQQBAQEnBycfCQgGExsHh2QEDJctn1eLERGFH2ADiECIf4NcgQ+EQYhAgWaCf4FA X-IronPort-AV: E=Sophos;i="4.75,714,1330905600"; d="scan'208";a="47644164" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 04 Jun 2012 22:09:19 +0000 Received: from [10.21.0.120] ([10.21.0.120]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q54M9IS7029392; Mon, 4 Jun 2012 22:09:18 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4FB94067.4010106@telia.com> Date: Mon, 4 Jun 2012 16:09:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1257) Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 22:09:20 -0000 Anders may not recall that I worked with Apple on this but I certainly = appreciate his praise. The basics are that an XML configuration profile is provided over HTTPS = which includes the configuration settings for a number of iOS aspects, = including subsequent certificate enrollment. The XML config instructs = the device to use SCEP, and further includes settings appropriate to = SCEP. The goal with EST is not to define this entire process, since device = configuration is not in the PKIX charter, but rather to define a profile = of CMC so that vendors like Apple can use it instead of SCEP or a = homegrown method. Some of the lessons learned have been incorporated = though. Unfortunately nothing about the Apple implementation of SCEP = informs us concerning the issue of this thread. I applaud Ander's for keeping the big picture in mind. - max On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: > IMO, Apple has a better solution to certificate enrollment than PKIX: >=20 > = http://developer.apple.com/library/ios/#documentation/NetworkingInternet/C= onceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >=20 > It works both for BYOD and consumers. Unlike traditional certificate > enrollment schemes, the Apple profile bootstrap can also provide VPN > settings in the the same step as certificates are enrolled! >=20 > In my own adoption of Apple's system, a server-based enrollment object = is > created before the actual profile and SCEP-request kicks in. The SCEP = DN > and challenge are only used for binding the SCEP request to the = enrollment > object. >=20 > Anders >=20 >=20 > On 2012-04-27 15:46, Alexander Truskovsky wrote: >> Max, >>=20 >> You are correct, the same problem exists if CMS is used. I think an = exception to the RFC 5280 key usage restrictions is reasonable in the = case of certificate renewal only. When verifying certificates you have = never seen before, I believe it is important to ensure the key usage is = appropriate and EST should perform full certificate verification when = authenticating the initial CSRs using certificates issued by another = PKI. In the case of certificate renewal the EST server will be = verifying certificates that it issued, and I think ignoring the key = usage here does not really degrade security. >>=20 >> We are interested in deploying a solution that will work for Client = Authentication and Email Protection certificates (enrollment and = renewal). I don't think that mobile devices have the need to support = enrollment for certificates with any other extended key usage. >>=20 >> I don't have any other suggestions right now. Perhaps the TLS client = authentication can still be used if it is more convenient to some = clients and CMS can be used as a secondary option. It is certainly = easier to override the key usage warning in the EST server = implementation when using CMS. >>=20 >> Regards, >> Alex >>=20 >>=20 >> -----Original Message----- >> From: Max Pritikin [mailto:pritikin@cisco.com]=20 >> Sent: Wednesday, April 25, 2012 7:20 PM >> To: Alexander Truskovsky >> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>=20 >>=20 >> Thank you for the feedback on EST (and SCEP).=20 >>=20 >> In regards for your request for EST functionality: >>=20 >> I agree that dealing with clients that can't use their certificates = for digitalSignature is a problem -- but doesn't the same problem exist = if the client's key usage is such that they shouldn't be signing = PKCS7/CMS either?=20 >>=20 >> "CMC provides a method to prove the client's identity based on a = client/server shared-secret" [RFC5272] ... but I don't believe it = provides an exception to the problem you're discussing. >>=20 >> Is there general interest in finding another approach? I've hesitated = to suggest an exception to the RFC5280 key usage restrictions but = haven't been able to think of a different approach.=20 >>=20 >> Do you have any suggestions? It is very possible I'm missing = something, >>=20 >> - max >>=20 >> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>=20 >>> Max, >>>=20 >>> I have been implementing the current SCEP draft, and have come = across several issues that we are glad to see addressed in EST, = specifically: >>>=20 >>> 1) The use of a certificate issued by another PKI to authenticate = the initial request is optional in SCEP. This is now a MUST requirement = in EST (A3). >>> 2) The GetCACaps response is not signed in SCEP. This is not a = problem in EST because of the TLS use. >>> 3) The SCEP draft mentions that RSA is the only algorithm supported = by the current implementations. Although there is no technical = limitation that prevents the usage of ECC in SCEP and some = implementations do support ECC, we are glad to see that algorithm = agility is a MUST requirement in EST (K1). >>>=20 >>> EST is a specification we would also consider deploying. There is = an additional use case we would like to see supported by EST. When = renewing an email protection certificate, it cannot be used to = authenticate the request using the TLS client authentication. Although = this can be achieved by using a full CMC operation, it would be better = if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and = signing it with the email protection key would work without having to = use a full CMC operation. >>>=20 >>> We think the use of TLS client authentication, although elegant, = makes it inconvenient to use in some cases because a full CMC operation = needs to be used. We propose to continue using PKCS7 to wrap the PKCS10 = to support this and similar use cases. >>>=20 >>> Thanks for your consideration, >>> Alex >>>=20 >>>=20 >>> Alexander Truskovsky >>> BlackBerry OS Security | Research In Motion >>>=20 >>>=20 >>> = --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain = confidential information, privileged material (including material = protected by the solicitor-client or other applicable privileges), or = constitute non-public information. Any use of this information by anyone = other than the intended recipient is prohibited. If you have received = this transmission in error, please immediately reply to the sender and = delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. >>=20 >>=20 >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain = confidential information, privileged material (including material = protected by the solicitor-client or other applicable privileges), or = constitute non-public information. Any use of this information by anyone = other than the intended recipient is prohibited. If you have received = this transmission in error, please immediately reply to the sender and = delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Mon Jun 4 22:30:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65211E8072 for ; Mon, 4 Jun 2012 22:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaQOaxwQWIRC for ; Mon, 4 Jun 2012 22:30:44 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8021F8720 for ; Mon, 4 Jun 2012 22:30:43 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FAE31D9005C501A; Tue, 5 Jun 2012 07:30:36 +0200 Message-ID: <4FCD9970.8070905@telia.com> Date: Tue, 05 Jun 2012 07:30:24 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Max Pritikin References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 05:30:46 -0000 Hi Max, Thank you for chiming in on this topic which in no way is limited to EST. As a CA developer and deployer at customer premises, I see that the practical consequences of not taking on the entire process is that systems get quite complex, and that you really never can be sure that they work since quite a big portion of the process is non-standard. Testing is true a nightmare :-( Cisco has solved this by having their own "standard" PKI client called AnyConnect. However, AnyConnect is not a part of Android or iPhone and has limited external documentation, making it fairly useless for other parties. Since Cisco and similar external vendors aren't allowed touching the mobile browser, AnyConnect (and its likes) doesn't offer a cool web interface like Apple do. Early adopters, like the Swedish banks, were forced creating their own enrollment "apps" since the lack of standards otherwise makes mobile PKI out of reach for consumers. Talking about standards, TrustedComputingGroup have (effectively) "outsourced" the development of web-based enrollment systems to Microsoft. Unfortunately Microsoft refuses sharing any details of their plans even with TCG members like me. Maybe particularly with me :-) :-) Regarding the web interface and the iOS solution, you might be interested in "how I tied the not between the web and iOS SCEP": The assumption is that the user is authenticated in the *web environment* and through that gets a session cookie. After successful authentication the iOS profile is delivered to the client which then "automagically" starts the enrollment process. Since SCEP doesn't support cookies (?), the SCEP URL provided in the XML profile is encoded like the following http://scephost/enroll;jsessionid=3D939427F4767E39E83F0BC43A370472 which enables the SCEP enrollment proxy to immediately reject SCEP requests not coming from properly authenticated users. Although working, it hopefully gives you an idea of the difficulties using PKIX enrollment protocols in a web world! AFAICT, NIST doesn't have any answers to this request from the Obama administration: http://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government-strategy.pdf Regards, Anders On 2012-06-05 00:09, Max Pritikin wrote: > > Anders may not recall that I worked with Apple on this but I certainly appreciate his praise. > > The basics are that an XML configuration profile is provided over HTTPS which includes the configuration settings for a number of iOS aspects, including subsequent certificate enrollment. The XML config instructs the device to use SCEP, and further includes settings appropriate to SCEP. > > The goal with EST is not to define this entire process, since device configuration is not in the PKIX charter, but rather to define a profile of CMC so that vendors like Apple can use it instead of SCEP or a homegrown method. Some of the lessons learned have been incorporated though. Unfortunately nothing about the Apple implementation of SCEP informs us concerning the issue of this thread. > > I applaud Ander's for keeping the big picture in mind. > > - max > > On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: > >> IMO, Apple has a better solution to certificate enrollment than PKIX: >> >> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >> >> It works both for BYOD and consumers. Unlike traditional certificate >> enrollment schemes, the Apple profile bootstrap can also provide VPN >> settings in the the same step as certificates are enrolled! >> >> In my own adoption of Apple's system, a server-based enrollment object is >> created before the actual profile and SCEP-request kicks in. The SCEP DN >> and challenge are only used for binding the SCEP request to the enrollment >> object. >> >> Anders >> >> >> On 2012-04-27 15:46, Alexander Truskovsky wrote: >>> Max, >>> >>> You are correct, the same problem exists if CMS is used. I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only. When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI. In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security. >>> >>> We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal). I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage. >>> >>> I don't have any other suggestions right now. Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option. It is certainly easier to override the key usage warning in the EST server implementation when using CMS. >>> >>> Regards, >>> Alex >>> >>> >>> -----Original Message----- >>> From: Max Pritikin [mailto:pritikin@cisco.com] >>> Sent: Wednesday, April 25, 2012 7:20 PM >>> To: Alexander Truskovsky >>> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >>> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>> >>> >>> Thank you for the feedback on EST (and SCEP). >>> >>> In regards for your request for EST functionality: >>> >>> I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? >>> >>> "CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing. >>> >>> Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. >>> >>> Do you have any suggestions? It is very possible I'm missing something, >>> >>> - max >>> >>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>> >>>> Max, >>>> >>>> I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically: >>>> >>>> 1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP. This is now a MUST requirement in EST (A3). >>>> 2) The GetCACaps response is not signed in SCEP. This is not a problem in EST because of the TLS use. >>>> 3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations. Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1). >>>> >>>> EST is a specification we would also consider deploying. There is an additional use case we would like to see supported by EST. When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication. Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation. >>>> >>>> We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used. We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases. >>>> >>>> Thanks for your consideration, >>>> Alex >>>> >>>> >>>> Alexander Truskovsky >>>> BlackBerry OS Security | Research In Motion >>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> _______________________________________________ >>> 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 > > From hallam@gmail.com Tue Jun 5 12:16:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E84221F865B for ; Tue, 5 Jun 2012 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcVhL6ZQLObG for ; Tue, 5 Jun 2012 12:16:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B273E21F8655 for ; Tue, 5 Jun 2012 12:16:28 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so848826obb.31 for ; Tue, 05 Jun 2012 12:16:28 -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 :cc:content-type:content-transfer-encoding; bh=dppSox6r5WPYjUJM3bArbo04Q5gbdk1i2Bzn9xMcLVA=; b=aqYHrpGMozKZE+hbyWNBqRVs1Er03HsiIkwNl0GNu8RN/zMHU6mAKUkxAwV9Pq5bgN k4eHZZI+bWMY7C4+3YHCvCXhZPlNqahdRNRY63Q++moFvxqmjSE5sTpHxaoSmxRfbEtG SsNNq0pXM/O04PxBT0fNE5kXSEyMmyfVAYki9wLY8xf3gvYcEQtrAeugjeUypci9Y1Gv KLEdGahIciEKGmakPTSgFUET5wmGcokDuApGRGyJ9jWzLKmpnY3ebHODdntn8+cIBU+Q Zy+Im06xByc6X4Kl2PFIOyOtcrALd/nkRQFr5WMCejq95RPH1yxnxrzD1VOmaXgpHrzf 11YQ== MIME-Version: 1.0 Received: by 10.182.40.71 with SMTP id v7mr18126045obk.5.1338923788195; Tue, 05 Jun 2012 12:16:28 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Tue, 5 Jun 2012 12:16:28 -0700 (PDT) In-Reply-To: <4FC8A5A1.7070103@comodo.com> References: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> <4FC7E512.3000801@comodo.com> <4FC8A5A1.7070103@comodo.com> Date: Tue, 5 Jun 2012 15:16:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 19:16:31 -0000 OCSP services were operational long before RFC 2459 was issued. They are not mentioned in RFC 2549 because that would have required that spec to be delayed until the OCSP spec was complete and it was already very late. I am really not sure why we did not get into signature bit settings in the OCSP spec. I suspect it had something to do with the way that the spec was changed from being a way that a CA publishes authoritative certificate status to being a way for anyone to assert certificate status. What is done is done, what matters is how we are going to operate going forward and what practical steps we can take to secure the Internet as best we can against the best efforts of foreign governments and parts of our own. On Fri, Jun 1, 2012 at 7:21 AM, Rob Stradling wr= ote: > On 01/06/12 08:48, denis.pinkas@bull.net wrote: >> >> Rob, >> >> I do not "buy" your argumentation, since it is based on RFC 2459 which >> is now obsolete and had two successors. >> Also, your argumentation is defeated, simply because RFC 2459 was issued >> before RFC 2560, which means before OCSP ever existed. > > > 2459 section 3.3 describes CRLs as just "one method of certificate > revocation" and then says "Message formats and protocols supporting on-li= ne > revocation notification may be defined in other PKIX specifications." > > So I think it's pretty clear that the authors of 2459 anticipated that ne= w > certificate revocation methods to be invented. > > >> As I already said on the list , at the time RFC 2560 was issued, we >> should have asked to ITU-T to add a OCSPsign key usage bit. > > > At the time 2560 was issued, 2459 was in force. =A0And 2459 says: > "The cRLSign bit is asserted when the subject public key is used for > verifying a signature on revocation information (e.g., a CRL)." > > OCSP Responses are "revocation information". =A0"e.g., a CRL" doesn't mea= n > "MUST be a CRL". > > So presumably the authors of 2560 believed "cRLSign" to be the applicable > Key Usage bit for Integrated Responder OCSP, but didn't feel the need to > express this in 2560 because 2459 already expressed it clearly. > > >> Nobody raised the point at the proper time. > > > It seems to me that there was no point to raise back then. =A02459 was cl= ear > that "cRLSign" was the appropriate bit to set. > > Then 3280 came along and (it seems) changed the rules without clearly > expressing (IMHO) what the new rules were. > > >> It seems too late now. So asserting instead the DS bit is not the > >> perfect solution, but it is the most acceptable. >> >> >> Denis >> >> >> >> >> De : Rob Stradling >> A : mrex@sap.com >> Cc : "pkix@ietf.org" >> Date : 31/05/2012 23:39 >> Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits >> Envoy=E9 par : pkix-bounces@ietf.org >> ------------------------------------------------------------------------ >> >> >> >> >> On 31/05/12 16:59, Martin Rex wrote: >> =A0> Rob Stradling wrote: >> =A0>> >> =A0>> Are you saying that trying to "fix" the standards is not really an >> option? >> =A0>> >> =A0>> What security hole would be introduced by once again allowing the >> =A0>> "crlSign" bit to authorize the CA certificate as an Integrated >> Responder? >> =A0> >> =A0> This is _NOT_ a defect of rfc2560, it was a conscious design decisi= on, >> =A0> and a careful implementor should have seen this. >> >> RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign >> bit is asserted when the subject public key is used for verifying a >> signature on revocation information (e.g., a CRL)." >> >> So if there was "a conscious design decision" by the RFC2560 authors >> regarding which Key Usage bits should be set in the Integrated Responder >> case, then surely that decision was in agreement with what I am asking >> for and in disagreement with the altered text in RFCs 3280 and 5280! >> >> =A0> So "fixing" does not exist as an option only changing the behaviour >> =A0> in a successor OCSP spec. But should still account for implementati= ons >> =A0> based on rfc2560 alone. >> >> And what about accounting for implementations based on RFC2459 alone? >> >> =A0> What is more confusing to me is that you're PKI software did not >> =A0> error on your attempt to sign OCSP responses without the >> =A0> DigitalSignature bit in your CA cert. When sensibly implemented, >> >> Our PKI software was written by me, and until this week I hadn't noticed >> that RFC3280/5280 changed the rules on which Key Usage bit means what. >> Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice >> sooner. Call me a careless implementor if you like. >> >> =A0>a signature creation function should perform a number of plausibilit= y >> =A0> checks on signature creation (including KeyUsage and Validity), >> =A0> because it does not make sense (other than in very limited debug >> =A0> situations) to create digital signatures that receipients will >> =A0> very probably fail verifying. >> >> Let's look at this from another angle: >> What would happen today if a CA decides to implement an >> RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? >> If they follow RFC5280's guidance, they will set keyCertSign and >> digitalSignature (but NOT cRLSign) in the CA Certificate(s). >> Then, what would happen when an RFC2459-compliant client attempts to >> perform an OCSP check on an end-entity certificate from this PKI? If >> the client enforces the RFC2459 definitions of the Key Usage bits, it >> would reject the OCSP Response because the CA Certificate does not have >> the cRLSign bit set!! >> >> =A0> -Martin >> =A0> >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online >> Office Tel: +44.(0)1274.730505 >> Office Fax: +44.(0)1274.730909 >> www.comodo.com >> >> COMODO CA Limited, Registered in England No. 04058690 >> Registered Office: >> 3rd Floor, 26 Office Village, Exchange Quay, >> Trafford Road, Salford, Manchester M5 3EQ >> >> This e-mail and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. If you have received this email in error please notify the >> sender by replying to the e-mail containing this attachment. Replies to >> this email may be monitored by COMODO for operational or business >> reasons. Whilst every endeavour is taken to ensure that e-mails are free >> from viruses, no liability can be accepted and the recipient is >> requested to use their own virus checking software. >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > =A03rd Floor, 26 Office Village, Exchange Quay, > =A0Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intend= ed > solely for the use of the individual or entity to whom they are addressed= . > =A0If you have received this email in error please notify the sender by > replying to the e-mail containing this attachment. Replies to this email = may > be monitored by COMODO for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no > liability can be accepted and the recipient is requested to use their own > virus checking software. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From turners@ieca.com Tue Jun 5 19:37:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338E211E80C9 for ; Tue, 5 Jun 2012 19:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgke8d9pRdCQ for ; Tue, 5 Jun 2012 19:37:26 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.233.8]) by ietfa.amsl.com (Postfix) with ESMTP id 147D111E80C0 for ; Tue, 5 Jun 2012 19:37:26 -0700 (PDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id DEAEE77ED601F for ; Tue, 5 Jun 2012 21:37:19 -0500 (CDT) Received: from [96.231.120.23] (port=35125 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sc67b-0005dg-6o; Tue, 05 Jun 2012 21:37:19 -0500 Message-ID: <4FCEC25E.9050509@ieca.com> Date: Tue, 05 Jun 2012 22:37:18 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Max Pritikin References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.120.23]:35125 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 02:37:27 -0000 Interesting ... In http://datatracker.ietf.org/doc/draft-turner-sodp/ there's a concept of Product Availability List (PAL). It's an XML file that clients can use to walk through the products (keys, firmware, etc.) that are available for it to download. spt On 6/4/12 6:09 PM, Max Pritikin wrote: > > Anders may not recall that I worked with Apple on this but I certainly appreciate his praise. > > The basics are that an XML configuration profile is provided over HTTPS which includes the configuration settings for a number of iOS aspects, including subsequent certificate enrollment. The XML config instructs the device to use SCEP, and further includes settings appropriate to SCEP. > > The goal with EST is not to define this entire process, since device configuration is not in the PKIX charter, but rather to define a profile of CMC so that vendors like Apple can use it instead of SCEP or a homegrown method. Some of the lessons learned have been incorporated though. Unfortunately nothing about the Apple implementation of SCEP informs us concerning the issue of this thread. > > I applaud Ander's for keeping the big picture in mind. > > - max > > On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: > >> IMO, Apple has a better solution to certificate enrollment than PKIX: >> >> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >> >> It works both for BYOD and consumers. Unlike traditional certificate >> enrollment schemes, the Apple profile bootstrap can also provide VPN >> settings in the the same step as certificates are enrolled! >> >> In my own adoption of Apple's system, a server-based enrollment object is >> created before the actual profile and SCEP-request kicks in. The SCEP DN >> and challenge are only used for binding the SCEP request to the enrollment >> object. >> >> Anders >> >> >> On 2012-04-27 15:46, Alexander Truskovsky wrote: >>> Max, >>> >>> You are correct, the same problem exists if CMS is used. I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only. When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI. In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security. >>> >>> We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal). I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage. >>> >>> I don't have any other suggestions right now. Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option. It is certainly easier to override the key usage warning in the EST server implementation when using CMS. >>> >>> Regards, >>> Alex >>> >>> >>> -----Original Message----- >>> From: Max Pritikin [mailto:pritikin@cisco.com] >>> Sent: Wednesday, April 25, 2012 7:20 PM >>> To: Alexander Truskovsky >>> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >>> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>> >>> >>> Thank you for the feedback on EST (and SCEP). >>> >>> In regards for your request for EST functionality: >>> >>> I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? >>> >>> "CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing. >>> >>> Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. >>> >>> Do you have any suggestions? It is very possible I'm missing something, >>> >>> - max >>> >>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>> >>>> Max, >>>> >>>> I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically: >>>> >>>> 1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP. This is now a MUST requirement in EST (A3). >>>> 2) The GetCACaps response is not signed in SCEP. This is not a problem in EST because of the TLS use. >>>> 3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations. Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1). >>>> >>>> EST is a specification we would also consider deploying. There is an additional use case we would like to see supported by EST. When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication. Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation. >>>> >>>> We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used. We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases. >>>> >>>> Thanks for your consideration, >>>> Alex >>>> >>>> >>>> Alexander Truskovsky >>>> BlackBerry OS Security | Research In Motion >>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> _______________________________________________ >>> 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From anders.rundgren@telia.com Tue Jun 5 22:14:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C3721F85DB for ; Tue, 5 Jun 2012 22:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF1DBoZ6sc+0 for ; Tue, 5 Jun 2012 22:14:36 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id DAF5721F85D7 for ; Tue, 5 Jun 2012 22:14:35 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FAE32940088DD0D; Wed, 6 Jun 2012 07:14:30 +0200 Message-ID: <4FCEE729.4090100@telia.com> Date: Wed, 06 Jun 2012 07:14:17 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sean Turner References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> <4FCEC25E.9050509@ieca.com> In-Reply-To: <4FCEC25E.9050509@ieca.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-sodp X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 05:14:37 -0000 Since I was CC:ed I guess I'm entitled commenting on this draft as well? http://www.ietf.org/id/draft-turner-sodp-02.txt I believe that comparing Apple's profile system (mentioned in the referenced mail), to PAL would be wrong because Apple's system follows the path that I have selected for my own work in this space, namely *server-centric object provisioning and management*. SCEP, EST, CMP, SODP etc. are all client-orchestrated solutions. IMHO, the web is more suited to server-centric solutions because the need for a new security object doesn't start at the client; it begins with a human user wanting to do something new, which may require a secure object like a virtual credit card. Although skimming the SKS/KeyGen2 docs indeed shows that it is the client that generates a key-pair, a deeper look will reveal that it does that as a response to a *server request*. That the scheme is server-centric seems like a prerequisite for being able to perform a sequence of secure operations in an atomic fashion (transaction), aided by a session-key using light-weight cryptography. Algorithm agility is also mainly a server (service) policy issue since it is the payment network (here taking on the virtual credit card example again...) that may prefer/require EC P-256 before RSA 2048. The PKI client or human user can hardly have much saying here. My gut-feeling is that the availability of embedded security hardware and NFC will accelerate the trend towards end-to-end-secured server-centric object-provisioning using session-keys. regards, Anders On 2012-06-06 04:37, Sean Turner wrote: > Interesting ... In http://datatracker.ietf.org/doc/draft-turner-sodp/ > there's a concept of Product Availability List (PAL). It's an XML file > that clients can use to walk through the products (keys, firmware, etc.) > that are available for it to download. > > spt > > On 6/4/12 6:09 PM, Max Pritikin wrote: >> >> Anders may not recall that I worked with Apple on this but I certainly appreciate his praise. >> >> The basics are that an XML configuration profile is provided over HTTPS which includes the configuration settings for a number of iOS aspects, including subsequent certificate enrollment. The XML config instructs the device to use SCEP, and further includes settings appropriate to SCEP. >> >> The goal with EST is not to define this entire process, since device configuration is not in the PKIX charter, but rather to define a profile of CMC so that vendors like Apple can use it instead of SCEP or a homegrown method. Some of the lessons learned have been incorporated though. Unfortunately nothing about the Apple implementation of SCEP informs us concerning the issue of this thread. >> >> I applaud Ander's for keeping the big picture in mind. >> >> - max >> >> On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: >> >>> IMO, Apple has a better solution to certificate enrollment than PKIX: >>> >>> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >>> >>> It works both for BYOD and consumers. Unlike traditional certificate >>> enrollment schemes, the Apple profile bootstrap can also provide VPN >>> settings in the the same step as certificates are enrolled! >>> >>> In my own adoption of Apple's system, a server-based enrollment object is >>> created before the actual profile and SCEP-request kicks in. The SCEP DN >>> and challenge are only used for binding the SCEP request to the enrollment >>> object. >>> >>> Anders >>> >>> >>> On 2012-04-27 15:46, Alexander Truskovsky wrote: >>>> Max, >>>> >>>> You are correct, the same problem exists if CMS is used. I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only. When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI. In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security. >>>> >>>> We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal). I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage. >>>> >>>> I don't have any other suggestions right now. Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option. It is certainly easier to override the key usage warning in the EST server implementation when using CMS. >>>> >>>> Regards, >>>> Alex >>>> >>>> >>>> -----Original Message----- >>>> From: Max Pritikin [mailto:pritikin@cisco.com] >>>> Sent: Wednesday, April 25, 2012 7:20 PM >>>> To: Alexander Truskovsky >>>> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >>>> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>>> >>>> >>>> Thank you for the feedback on EST (and SCEP). >>>> >>>> In regards for your request for EST functionality: >>>> >>>> I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? >>>> >>>> "CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing. >>>> >>>> Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. >>>> >>>> Do you have any suggestions? It is very possible I'm missing something, >>>> >>>> - max >>>> >>>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>>> >>>>> Max, >>>>> >>>>> I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically: >>>>> >>>>> 1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP. This is now a MUST requirement in EST (A3). >>>>> 2) The GetCACaps response is not signed in SCEP. This is not a problem in EST because of the TLS use. >>>>> 3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations. Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1). >>>>> >>>>> EST is a specification we would also consider deploying. There is an additional use case we would like to see supported by EST. When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication. Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation. >>>>> >>>>> We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used. We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases. >>>>> >>>>> Thanks for your consideration, >>>>> Alex >>>>> >>>>> >>>>> Alexander Truskovsky >>>>> BlackBerry OS Security | Research In Motion >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > From turners@ieca.com Wed Jun 6 04:27:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C2421F85C6 for ; Wed, 6 Jun 2012 04:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.757 X-Spam-Level: X-Spam-Status: No, score=-101.757 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5IDm8mWVRuf for ; Wed, 6 Jun 2012 04:27:53 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.179.5]) by ietfa.amsl.com (Postfix) with ESMTP id E35E721F85FD for ; Wed, 6 Jun 2012 04:27:52 -0700 (PDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 3DDA87A9C0F74 for ; Wed, 6 Jun 2012 06:27:52 -0500 (CDT) Received: from [96.231.120.23] (port=48049 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ScEP0-0005TG-B0; Wed, 06 Jun 2012 06:27:51 -0500 Message-ID: <4FCF3EB5.3050400@ieca.com> Date: Wed, 06 Jun 2012 07:27:49 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Anders Rundgren References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> <4FCEC25E.9050509@ieca.com> <4FCEE729.4090100@telia.com> In-Reply-To: <4FCEE729.4090100@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.120.23]:48049 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-sodp X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 11:27:54 -0000 Anders, You're always welcome to comment. Some more inline... spt On 6/6/12 1:14 AM, Anders Rundgren wrote: > Since I was CC:ed I guess I'm entitled commenting on this draft as well? > http://www.ietf.org/id/draft-turner-sodp-02.txt > > I believe that comparing Apple's profile system (mentioned in the > referenced mail), to PAL would be wrong because Apple's system follows > the path that I have selected for my own work in this space, namely > *server-centric object provisioning and management*. > > SCEP, EST, CMP, SODP etc. are all client-orchestrated solutions. Hmm not entirely so. In SODP, server-requested rekeys are supported. The idea is that the client comes preloaded with a cert that it uses to do mutual authentication with the server, and the first thing the client will see in the PAL is a notice from the server that says please rekey. > IMHO, the web is more suited to server-centric solutions because the > need for a new security object doesn't start at the client; it begins > with a human user wanting to do something new, which may require a > secure object like a virtual credit card. > > Although skimming the SKS/KeyGen2 docs indeed shows that it is the > client that generates a key-pair, a deeper look will reveal that it > does that as a response to a *server request*. That the scheme is > server-centric seems like a prerequisite for being able to perform > a sequence of secure operations in an atomic fashion (transaction), > aided by a session-key using light-weight cryptography. > > Algorithm agility is also mainly a server (service) policy issue since > it is the payment network (here taking on the virtual credit card > example again...) that may prefer/require EC P-256 before RSA 2048. > The PKI client or human user can hardly have much saying here. > > My gut-feeling is that the availability of embedded security hardware > and NFC will accelerate the trend towards end-to-end-secured > server-centric object-provisioning using session-keys. > > regards, > Anders > > > On 2012-06-06 04:37, Sean Turner wrote: >> Interesting ... In http://datatracker.ietf.org/doc/draft-turner-sodp/ >> there's a concept of Product Availability List (PAL). It's an XML file >> that clients can use to walk through the products (keys, firmware, etc.) >> that are available for it to download. >> >> spt >> >> On 6/4/12 6:09 PM, Max Pritikin wrote: >>> >>> Anders may not recall that I worked with Apple on this but I certainly appreciate his praise. >>> >>> The basics are that an XML configuration profile is provided over HTTPS which includes the configuration settings for a number of iOS aspects, including subsequent certificate enrollment. The XML config instructs the device to use SCEP, and further includes settings appropriate to SCEP. >>> >>> The goal with EST is not to define this entire process, since device configuration is not in the PKIX charter, but rather to define a profile of CMC so that vendors like Apple can use it instead of SCEP or a homegrown method. Some of the lessons learned have been incorporated though. Unfortunately nothing about the Apple implementation of SCEP informs us concerning the issue of this thread. >>> >>> I applaud Ander's for keeping the big picture in mind. >>> >>> - max >>> >>> On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: >>> >>>> IMO, Apple has a better solution to certificate enrollment than PKIX: >>>> >>>> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >>>> >>>> It works both for BYOD and consumers. Unlike traditional certificate >>>> enrollment schemes, the Apple profile bootstrap can also provide VPN >>>> settings in the the same step as certificates are enrolled! >>>> >>>> In my own adoption of Apple's system, a server-based enrollment object is >>>> created before the actual profile and SCEP-request kicks in. The SCEP DN >>>> and challenge are only used for binding the SCEP request to the enrollment >>>> object. >>>> >>>> Anders >>>> >>>> >>>> On 2012-04-27 15:46, Alexander Truskovsky wrote: >>>>> Max, >>>>> >>>>> You are correct, the same problem exists if CMS is used. I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only. When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI. In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security. >>>>> >>>>> We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal). I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage. >>>>> >>>>> I don't have any other suggestions right now. Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option. It is certainly easier to override the key usage warning in the EST server implementation when using CMS. >>>>> >>>>> Regards, >>>>> Alex >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Max Pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Wednesday, April 25, 2012 7:20 PM >>>>> To: Alexander Truskovsky >>>>> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >>>>> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>>>> >>>>> >>>>> Thank you for the feedback on EST (and SCEP). >>>>> >>>>> In regards for your request for EST functionality: >>>>> >>>>> I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? >>>>> >>>>> "CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing. >>>>> >>>>> Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. >>>>> >>>>> Do you have any suggestions? It is very possible I'm missing something, >>>>> >>>>> - max >>>>> >>>>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically: >>>>>> >>>>>> 1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP. This is now a MUST requirement in EST (A3). >>>>>> 2) The GetCACaps response is not signed in SCEP. This is not a problem in EST because of the TLS use. >>>>>> 3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations. Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1). >>>>>> >>>>>> EST is a specification we would also consider deploying. There is an additional use case we would like to see supported by EST. When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication. Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation. >>>>>> >>>>>> We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used. We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases. >>>>>> >>>>>> Thanks for your consideration, >>>>>> Alex >>>>>> >>>>>> >>>>>> Alexander Truskovsky >>>>>> BlackBerry OS Security | Research In Motion >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> > > From stephen.farrell@cs.tcd.ie Wed Jun 6 04:30:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07A21F8755 for ; Wed, 6 Jun 2012 04:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaUP7QWLltG1 for ; Wed, 6 Jun 2012 04:30:57 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27421F87FF for ; Wed, 6 Jun 2012 04:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D4C3E18F387 for ; Wed, 6 Jun 2012 12:30:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338982255; bh=DwMwh5a0e22Bed E/W99AIS8EZo1Vv/XEIv/a7xl35es=; b=40jV8XiXxaIre5FZea9/XEXRPFgmm4 hGZPlLAjMLXaev07d/+I8v60q/w1TgFVAKtgJJv15gXVt6iAOGXwZapt6g8nCi7M HJ69aewiZ+5u/neDlxhyLudObBs8RJBFi1j9WLyQtb1UMJyNtMdA0I3aAHzOHjUn XzfUQf/vx088Ay9CFeTI+LGCWPUDc2WuiIVyWslrPB1vGmr0j4MDnr4iBao3s6bn U3uERFX19rK5nc/lcSfiTj/rszof5/QMkspnFmxvj9cEWOv7KR3bbu4CftSMwJQ5 zGM7qU6FEXmiww2KTMKB0ECoO5tBa8EJ5opqV62R885ViWY5Rxp2T5sw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 35U+-zk7cwjS for ; Wed, 6 Jun 2012 12:30:55 +0100 (IST) Received: from [IPv6:2001:770:10:203:bd88:d721:7222:9395] (unknown [IPv6:2001:770:10:203:bd88:d721:7222:9395]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6569916F4BC for ; Wed, 6 Jun 2012 12:30:55 +0100 (IST) Message-ID: <4FCF3F70.5000807@cs.tcd.ie> Date: Wed, 06 Jun 2012 12:30:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix References: <4FCF3F47.10205@cs.tcd.ie> In-Reply-To: <4FCF3F47.10205@cs.tcd.ie> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <4FCF3F47.10205@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Fwd: RFC 5742 review of draft-hotz-kx509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 11:30:57 -0000 FYI -------- Original Message -------- Subject: RFC 5742 review of draft-hotz-kx509 Date: Wed, 06 Jun 2012 12:30:15 +0100 From: Stephen Farrell To: Russ Allbery , draft-hotz-kx509@tools.ietf.org, Nevil Brownlee CC: Stephen Farrell Hi, I've done my 5742 review of this and reckon that its doesn't conflict with the planned work on the topic in the kerberos WG, so I've put this on the June 21st IESG telechat agenda for the other ADs to see if they agree or not. Note that I also had some comments on the text itself. [1] The authors/ISE might want to take a look at those in the meantime, in particular the IANA registration comment. (Authors - I think the right thing here is to do what the ISE wants in terms of any possible revisions, but from the IESG point of view, I'd guess changes you might want to make to address those comments if made in the next week wouldn't be a problem.) Cheers, Stephen. [1] https://datatracker.ietf.org/doc/draft-hotz-kx509/writeup/ On 05/31/2012 12:35 AM, Stephen Farrell wrote: > > Hi, > > The independent submissions editor (ISE) has asked the > IESG to do an RFC 5742 review of this [1] document. > > That review is to check that the publication of this > independent stream submission would not conflict with > IETF work. > > In this case, the work is clearly related to the pkix > and kerberos working groups, hence this mail. > > Note: this mail is not a request for a technical review > of the content, but rather asking if publication would > somehow be damaging to the work of these wgs. (If you > do have technical comments, send them to the author > or ISE). If you're not sure about any of that, then > read RFC 5742. [2] > > I'll take silence as meaning that nobody thinks that > there's a conflict. If someone thinks there is a > conflict let me, the list, or the wg chairs know. In > due course, I'll be doing my own evaluation as well > of course, as will other IESG members. > > Thanks, > Stephen. > > [1] http://tools.ietf.org/html/draft-hotz-kx509-04 > [2] http://tools.ietf.org/html/rfc5742 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > From dharkins@lounge.org Wed Jun 6 17:41:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A02011E8087 for ; Wed, 6 Jun 2012 17:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEpJkahcZsQC for ; Wed, 6 Jun 2012 17:41:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 13E5611E809C for ; Wed, 6 Jun 2012 17:41:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BF94110224008; Wed, 6 Jun 2012 17:41:26 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Jun 2012 17:41:26 -0700 (PDT) Message-ID: In-Reply-To: <4FCEC25E.9050509@ieca.com> References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> <4FCEC25E.9050509@ieca.com> Date: Wed, 6 Jun 2012 17:41:26 -0700 (PDT) From: "Dan Harkins" To: "Sean Turner" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 00:41:28 -0000 What's needed isn't keys or firmware, it's data to configure a particular protocol on the client to use the certificates it got from EST. For example, if it's wifi, then the xml config would include something like what SSID to connect to and what EAP method it should use (presumably EAP-TLS, but who knows). For IPsec the config would say what gateway the client should connect to, how often it should reauthenticate, it could maybe even provide some data to add to the SPD. Upon receipt of the xml blob, the device configures itself to use the certificates. Dan. On Tue, June 5, 2012 7:37 pm, Sean Turner wrote: > Interesting ... In http://datatracker.ietf.org/doc/draft-turner-sodp/ > there's a concept of Product Availability List (PAL). It's an XML file > that clients can use to walk through the products (keys, firmware, etc.) > that are available for it to download. > > spt > > On 6/4/12 6:09 PM, Max Pritikin wrote: >> >> Anders may not recall that I worked with Apple on this but I certainly >> appreciate his praise. >> >> The basics are that an XML configuration profile is provided over HTTPS >> which includes the configuration settings for a number of iOS aspects, >> including subsequent certificate enrollment. The XML config instructs >> the device to use SCEP, and further includes settings appropriate to >> SCEP. >> >> The goal with EST is not to define this entire process, since device >> configuration is not in the PKIX charter, but rather to define a profile >> of CMC so that vendors like Apple can use it instead of SCEP or a >> homegrown method. Some of the lessons learned have been incorporated >> though. Unfortunately nothing about the Apple implementation of SCEP >> informs us concerning the issue of this thread. >> >> I applaud Ander's for keeping the big picture in mind. >> >> - max >> >> On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: >> >>> IMO, Apple has a better solution to certificate enrollment than PKIX: >>> >>> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >>> >>> It works both for BYOD and consumers. Unlike traditional certificate >>> enrollment schemes, the Apple profile bootstrap can also provide VPN >>> settings in the the same step as certificates are enrolled! >>> >>> In my own adoption of Apple's system, a server-based enrollment object >>> is >>> created before the actual profile and SCEP-request kicks in. The SCEP >>> DN >>> and challenge are only used for binding the SCEP request to the >>> enrollment >>> object. >>> >>> Anders >>> >>> >>> On 2012-04-27 15:46, Alexander Truskovsky wrote: >>>> Max, >>>> >>>> You are correct, the same problem exists if CMS is used. I think an >>>> exception to the RFC 5280 key usage restrictions is reasonable in the >>>> case of certificate renewal only. When verifying certificates you >>>> have never seen before, I believe it is important to ensure the key >>>> usage is appropriate and EST should perform full certificate >>>> verification when authenticating the initial CSRs using certificates >>>> issued by another PKI. In the case of certificate renewal the EST >>>> server will be verifying certificates that it issued, and I think >>>> ignoring the key usage here does not really degrade security. >>>> >>>> We are interested in deploying a solution that will work for Client >>>> Authentication and Email Protection certificates (enrollment and >>>> renewal). I don't think that mobile devices have the need to support >>>> enrollment for certificates with any other extended key usage. >>>> >>>> I don't have any other suggestions right now. Perhaps the TLS client >>>> authentication can still be used if it is more convenient to some >>>> clients and CMS can be used as a secondary option. It is certainly >>>> easier to override the key usage warning in the EST server >>>> implementation when using CMS. >>>> >>>> Regards, >>>> Alex >>>> >>>> >>>> -----Original Message----- >>>> From: Max Pritikin [mailto:pritikin@cisco.com] >>>> Sent: Wednesday, April 25, 2012 7:20 PM >>>> To: Alexander Truskovsky >>>> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >>>> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>>> >>>> >>>> Thank you for the feedback on EST (and SCEP). >>>> >>>> In regards for your request for EST functionality: >>>> >>>> I agree that dealing with clients that can't use their certificates >>>> for digitalSignature is a problem -- but doesn't the same problem >>>> exist if the client's key usage is such that they shouldn't be signing >>>> PKCS7/CMS either? >>>> >>>> "CMC provides a method to prove the client's identity based on a >>>> client/server shared-secret" [RFC5272] ... but I don't believe it >>>> provides an exception to the problem you're discussing. >>>> >>>> Is there general interest in finding another approach? I've hesitated >>>> to suggest an exception to the RFC5280 key usage restrictions but >>>> haven't been able to think of a different approach. >>>> >>>> Do you have any suggestions? It is very possible I'm missing >>>> something, >>>> >>>> - max >>>> >>>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>>> >>>>> Max, >>>>> >>>>> I have been implementing the current SCEP draft, and have come across >>>>> several issues that we are glad to see addressed in EST, >>>>> specifically: >>>>> >>>>> 1) The use of a certificate issued by another PKI to authenticate the >>>>> initial request is optional in SCEP. This is now a MUST requirement >>>>> in EST (A3). >>>>> 2) The GetCACaps response is not signed in SCEP. This is not a >>>>> problem in EST because of the TLS use. >>>>> 3) The SCEP draft mentions that RSA is the only algorithm supported >>>>> by the current implementations. Although there is no technical >>>>> limitation that prevents the usage of ECC in SCEP and some >>>>> implementations do support ECC, we are glad to see that algorithm >>>>> agility is a MUST requirement in EST (K1). >>>>> >>>>> EST is a specification we would also consider deploying. There is an >>>>> additional use case we would like to see supported by EST. When >>>>> renewing an email protection certificate, it cannot be used to >>>>> authenticate the request using the TLS client authentication. >>>>> Although this can be achieved by using a full CMC operation, it would >>>>> be better if it were handled by plain EST. Wrapping the PKCS10 in >>>>> PKCS7 and signing it with the email protection key would work without >>>>> having to use a full CMC operation. >>>>> >>>>> We think the use of TLS client authentication, although elegant, >>>>> makes it inconvenient to use in some cases because a full CMC >>>>> operation needs to be used. We propose to continue using PKCS7 to >>>>> wrap the PKCS10 to support this and similar use cases. >>>>> >>>>> Thanks for your consideration, >>>>> Alex >>>>> >>>>> >>>>> Alexander Truskovsky >>>>> BlackBerry OS Security | Research In Motion >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material >>>>> protected by the solicitor-client or other applicable privileges), or >>>>> constitute non-public information. Any use of this information by >>>>> anyone other than the intended recipient is prohibited. If you have >>>>> received this transmission in error, please immediately reply to the >>>>> sender and delete this information from your system. Use, >>>>> dissemination, distribution, or reproduction of this transmission by >>>>> unintended recipients is not authorized and may be unlawful. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential >>>> information, privileged material (including material protected by the >>>> solicitor-client or other applicable privileges), or constitute >>>> non-public information. Any use of this information by anyone other >>>> than the intended recipient is prohibited. If you have received this >>>> transmission in error, please immediately reply to the sender and >>>> delete this information from your system. Use, dissemination, >>>> distribution, or reproduction of this transmission by unintended >>>> recipients is not authorized and may be unlawful. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 > From anders.rundgren@telia.com Wed Jun 6 22:17:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719AE21F86A1 for ; Wed, 6 Jun 2012 22:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krIOLCa2Y9qg for ; Wed, 6 Jun 2012 22:17:43 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id D025921F84FB for ; Wed, 6 Jun 2012 22:17:41 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FA80EAF00AD93DB; Thu, 7 Jun 2012 07:17:36 +0200 Message-ID: <4FD03961.1010808@telia.com> Date: Thu, 07 Jun 2012 07:17:21 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dan Harkins References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> <4FB94067.4010106@telia.com> <4FCEC25E.9050509@ieca.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 05:17:44 -0000 On 2012-06-07 02:41, Dan Harkins wrote: > > What's needed isn't keys or firmware, it's data to configure a particular > protocol on the client to use the certificates it got from EST. For example, > if it's wifi, then the xml config would include something like what SSID to > connect to and what EAP method it should use (presumably EAP-TLS, but > who knows). For IPsec the config would say what gateway the client should > connect to, how often it should reauthenticate, it could maybe even provide > some data to add to the SPD. Upon receipt of the xml blob, the device > configures itself to use the certificates. Yes. That's pretty much what Apple's already implemented scheme does. What's more, you can perform this over the web. The SCEP profile entry contains the challenge as well which effectively moves the actual authentication to the invoking web application which allows you to use any method from e-mail round-trip, to AD/Kerberos, to passwords. That is, in a web-centric enrollment system you do not really want *user authentication* inside of the protocol. Regarding Sean's SODP, it appears to be a universal security object management system building on EST. Going back to the core, Apple still doesn't support enrollment of two-factor authentication tokens like keys protected by PIN-codes which is one of many reasons why they some day will have to switch to another system. Using PKIX protocols isn't an option since these do not address two-factor authentication. In addition, Apple probably needs to add support for end-to-end-security (w r t the *cryptographic container*) which also is outside of the PKIX charter. The cryptographic processor will most certainly be a part of the standard CPU because the cost in terms of silicon is less than 0.1 mm2 and it is anyway a prerequisite for thwarting "jail-breaking". Anders > > Dan. > > On Tue, June 5, 2012 7:37 pm, Sean Turner wrote: >> Interesting ... In http://datatracker.ietf.org/doc/draft-turner-sodp/ >> there's a concept of Product Availability List (PAL). It's an XML file >> that clients can use to walk through the products (keys, firmware, etc.) >> that are available for it to download. >> >> spt >> >> On 6/4/12 6:09 PM, Max Pritikin wrote: >>> >>> Anders may not recall that I worked with Apple on this but I certainly >>> appreciate his praise. >>> >>> The basics are that an XML configuration profile is provided over HTTPS >>> which includes the configuration settings for a number of iOS aspects, >>> including subsequent certificate enrollment. The XML config instructs >>> the device to use SCEP, and further includes settings appropriate to >>> SCEP. >>> >>> The goal with EST is not to define this entire process, since device >>> configuration is not in the PKIX charter, but rather to define a profile >>> of CMC so that vendors like Apple can use it instead of SCEP or a >>> homegrown method. Some of the lessons learned have been incorporated >>> though. Unfortunately nothing about the Apple implementation of SCEP >>> informs us concerning the issue of this thread. >>> >>> I applaud Ander's for keeping the big picture in mind. >>> >>> - max >>> >>> On May 20, 2012, at 1:05 PM, Anders Rundgren wrote: >>> >>>> IMO, Apple has a better solution to certificate enrollment than PKIX: >>>> >>>> http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html >>>> >>>> It works both for BYOD and consumers. Unlike traditional certificate >>>> enrollment schemes, the Apple profile bootstrap can also provide VPN >>>> settings in the the same step as certificates are enrolled! >>>> >>>> In my own adoption of Apple's system, a server-based enrollment object >>>> is >>>> created before the actual profile and SCEP-request kicks in. The SCEP >>>> DN >>>> and challenge are only used for binding the SCEP request to the >>>> enrollment >>>> object. >>>> >>>> Anders >>>> >>>> >>>> On 2012-04-27 15:46, Alexander Truskovsky wrote: >>>>> Max, >>>>> >>>>> You are correct, the same problem exists if CMS is used. I think an >>>>> exception to the RFC 5280 key usage restrictions is reasonable in the >>>>> case of certificate renewal only. When verifying certificates you >>>>> have never seen before, I believe it is important to ensure the key >>>>> usage is appropriate and EST should perform full certificate >>>>> verification when authenticating the initial CSRs using certificates >>>>> issued by another PKI. In the case of certificate renewal the EST >>>>> server will be verifying certificates that it issued, and I think >>>>> ignoring the key usage here does not really degrade security. >>>>> >>>>> We are interested in deploying a solution that will work for Client >>>>> Authentication and Email Protection certificates (enrollment and >>>>> renewal). I don't think that mobile devices have the need to support >>>>> enrollment for certificates with any other extended key usage. >>>>> >>>>> I don't have any other suggestions right now. Perhaps the TLS client >>>>> authentication can still be used if it is more convenient to some >>>>> clients and CMS can be used as a secondary option. It is certainly >>>>> easier to override the key usage warning in the EST server >>>>> implementation when using CMS. >>>>> >>>>> Regards, >>>>> Alex >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Max Pritikin [mailto:pritikin@cisco.com] >>>>> Sent: Wednesday, April 25, 2012 7:20 PM >>>>> To: Alexander Truskovsky >>>>> Cc: pkix@ietf.org; Matthew Campagna; Chris Bender >>>>> Subject: Re: Some comments on draft-ietf-pkix-est-01 >>>>> >>>>> >>>>> Thank you for the feedback on EST (and SCEP). >>>>> >>>>> In regards for your request for EST functionality: >>>>> >>>>> I agree that dealing with clients that can't use their certificates >>>>> for digitalSignature is a problem -- but doesn't the same problem >>>>> exist if the client's key usage is such that they shouldn't be signing >>>>> PKCS7/CMS either? >>>>> >>>>> "CMC provides a method to prove the client's identity based on a >>>>> client/server shared-secret" [RFC5272] ... but I don't believe it >>>>> provides an exception to the problem you're discussing. >>>>> >>>>> Is there general interest in finding another approach? I've hesitated >>>>> to suggest an exception to the RFC5280 key usage restrictions but >>>>> haven't been able to think of a different approach. >>>>> >>>>> Do you have any suggestions? It is very possible I'm missing >>>>> something, >>>>> >>>>> - max >>>>> >>>>> On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> I have been implementing the current SCEP draft, and have come across >>>>>> several issues that we are glad to see addressed in EST, >>>>>> specifically: >>>>>> >>>>>> 1) The use of a certificate issued by another PKI to authenticate the >>>>>> initial request is optional in SCEP. This is now a MUST requirement >>>>>> in EST (A3). >>>>>> 2) The GetCACaps response is not signed in SCEP. This is not a >>>>>> problem in EST because of the TLS use. >>>>>> 3) The SCEP draft mentions that RSA is the only algorithm supported >>>>>> by the current implementations. Although there is no technical >>>>>> limitation that prevents the usage of ECC in SCEP and some >>>>>> implementations do support ECC, we are glad to see that algorithm >>>>>> agility is a MUST requirement in EST (K1). >>>>>> >>>>>> EST is a specification we would also consider deploying. There is an >>>>>> additional use case we would like to see supported by EST. When >>>>>> renewing an email protection certificate, it cannot be used to >>>>>> authenticate the request using the TLS client authentication. >>>>>> Although this can be achieved by using a full CMC operation, it would >>>>>> be better if it were handled by plain EST. Wrapping the PKCS10 in >>>>>> PKCS7 and signing it with the email protection key would work without >>>>>> having to use a full CMC operation. >>>>>> >>>>>> We think the use of TLS client authentication, although elegant, >>>>>> makes it inconvenient to use in some cases because a full CMC >>>>>> operation needs to be used. We propose to continue using PKCS7 to >>>>>> wrap the PKCS10 to support this and similar use cases. >>>>>> >>>>>> Thanks for your consideration, >>>>>> Alex >>>>>> >>>>>> >>>>>> Alexander Truskovsky >>>>>> BlackBerry OS Security | Research In Motion >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> This transmission (including any attachments) may contain >>>>>> confidential information, privileged material (including material >>>>>> protected by the solicitor-client or other applicable privileges), or >>>>>> constitute non-public information. Any use of this information by >>>>>> anyone other than the intended recipient is prohibited. If you have >>>>>> received this transmission in error, please immediately reply to the >>>>>> sender and delete this information from your system. Use, >>>>>> dissemination, distribution, or reproduction of this transmission by >>>>>> unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential >>>>> information, privileged material (including material protected by the >>>>> solicitor-client or other applicable privileges), or constitute >>>>> non-public information. Any use of this information by anyone other >>>>> than the intended recipient is prohibited. If you have received this >>>>> transmission in error, please immediately reply to the sender and >>>>> delete this information from your system. Use, dissemination, >>>>> distribution, or reproduction of this transmission by unintended >>>>> recipients is not authorized and may be unlawful. >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From tmiller@mitre.org Mon Jun 11 06:50:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686BB21F85BD for ; Mon, 11 Jun 2012 06:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtvAe4WFHKHf for ; Mon, 11 Jun 2012 06:50:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA9921F84FB for ; Mon, 11 Jun 2012 06:50:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8634A21B0C34 for ; Mon, 11 Jun 2012 09:50:06 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4A12A21B0BBE for ; Mon, 11 Jun 2012 09:50:06 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.47]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Mon, 11 Jun 2012 09:50:06 -0400 From: "Miller, Timothy J." To: IETF PKIX Thread-Topic: A different question on NC... Thread-Index: AQHNR9kbbL/Q7VN6DEOjUsH9VgL8VQ== Date: Mon, 11 Jun 2012 13:50:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.171.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <7983E3BE682E4444BF8030FE4DC69E5F@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pkix] A different question on NC... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 13:50:10 -0000 Just to change a recent topic, if I wanted to completely prohibit a subordinate CA from issuing a particular name type (as opposed to restricting a name space), how would this be accomplished? IOW, if I wanted to restrict a sub-CA from issuing certificates containing any rfc822Name at all, what can I assert in the sub-CA cert? Would a critical NC with a null string in a permittedSubtrees base value work? Something else? Not possible under the spec? Enquiring minds want to know! :) Ignore implementations for the moment; theory only is fine for my current (nefarious?) purposes. =20 -- T From david.cooper@nist.gov Mon Jun 11 07:33:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025F021F8633 for ; Mon, 11 Jun 2012 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXGHQ1QC-ILc for ; Mon, 11 Jun 2012 07:33:47 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6421F8622 for ; Mon, 11 Jun 2012 07:33:46 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Jun 2012 10:33:32 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Jun 2012 10:31:29 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q5BEXjRh028382; Mon, 11 Jun 2012 10:33:45 -0400 Message-ID: <4FD601C9.2000804@nist.gov> Date: Mon, 11 Jun 2012 10:33:45 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120609 Thunderbird/13.0 MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] A different question on NC... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:33:48 -0000 Including a nameConstraints extension in a certificate does not prohibit the subject CA from issuing certificates with certain contents; it prevents the issuing CA's relying parties from accepting such certificates. It is an important distinction that seems to be lost on many people on this list. The nameConstraints extension wasn't really designed to allow the issuing CA to indicate that any certificate containing a name of a particular name form should be rejected. However, there may be ways to accomplish what you want. For name forms for which nameConstraints semantics have been defined, the solution is straightforward. Just specify the same or overlapping values for permitted and excluded subtrees. For example, for rfc822Name an excluded subtree of ".com" and a permitted subtree of ".com" or "example.com" or "fake.mailbox@example.com" Since no rfc822Name can satisfy both the permitted and excluded subtrees, the presence of any rfc822Name in the subjectAltName extension of a subsequent certificate will cause certification path validation to fail. If no nameConstraints semantics have been defined for the name type, then the situation is more tricky. RFC 5280 says: If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate. This implies that path validation software may accept a certification path even if it contains a nameConstraint that it cannot process as long as that name form does not appear in any subsequent certificate in the certification path. So, it might be possible to just use some arbitrary value for the nameConstraints extension (perhaps placing the same value in both a permitted and excluded subtree), but I can't say how well that would work with real-world implementations. On 06/11/2012 09:50 AM, Miller, Timothy J. wrote: > Just to change a recent topic, if I wanted to completely prohibit a > subordinate CA from issuing a particular name type (as opposed to > restricting a name space), how would this be accomplished? IOW, if I > wanted to restrict a sub-CA from issuing certificates containing any > rfc822Name at all, what can I assert in the sub-CA cert? > > Would a critical NC with a null string in a permittedSubtrees base value > work? Something else? Not possible under the spec? Enquiring minds want > to know! :) > > Ignore implementations for the moment; theory only is fine for my current > (nefarious?) purposes. > > -- T From tmiller@mitre.org Mon Jun 11 07:56:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653A821F863F for ; Mon, 11 Jun 2012 07:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW+8cab9Exmb for ; Mon, 11 Jun 2012 07:56:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7644C21F8611 for ; Mon, 11 Jun 2012 07:56:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F41C21B1A9E; Mon, 11 Jun 2012 10:56:34 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9421E21B1A9D; Mon, 11 Jun 2012 10:56:34 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.47]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Mon, 11 Jun 2012 10:56:34 -0400 From: "Miller, Timothy J." To: "David A. Cooper" Thread-Topic: [pkix] A different question on NC... Thread-Index: AQHNR9kbbL/Q7VN6DEOjUsH9VgL8VZb1ccWA//+yjAA= Date: Mon, 11 Jun 2012 14:56:34 +0000 Message-ID: In-Reply-To: <4FD601C9.2000804@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.171.187] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BB8ED53DE431641BEFBE01671A261C2@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] A different question on NC... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:56:41 -0000 On 6/11/12 9:33 AM, "David A. Cooper" wrote: >Including a nameConstraints extension in a certificate does not prohibit >the subject CA from issuing certificates with certain contents; it >prevents the issuing CA's relying parties from accepting such >certificates. It is an important distinction that seems to be lost on >many people on this list. Fair enough. Suffice to say that this may be good enough for my purposes. >The nameConstraints extension wasn't really designed to allow the >issuing CA to indicate that any certificate containing a name of a >particular name form should be rejected. As a side question--should it be (re)designed(/interpreted) with this in mind? Would such a control alleviate any currently known risks? >For name forms for which nameConstraints semantics have been defined, >the solution is straightforward. Just specify the same or overlapping >values for permitted and excluded subtrees. For example, for rfc822Name >an excluded subtree of ".com" and a permitted subtree of ".com" or >"example.com" or "fake.mailbox@example.com" Since no rfc822Name can >satisfy both the permitted and excluded subtrees, the presence of any >rfc822Name in the subjectAltName extension of a subsequent certificate >will cause certification path validation to fail. Now why didn't I think of that? Good observation; thanks much. >This implies that path validation software may accept a certification >path even if it contains a nameConstraint that it cannot process as long >as that name form does not appear in any subsequent certificate in the >certification path. So, it might be possible to just use some arbitrary >value for the nameConstraints extension (perhaps placing the same value >in both a permitted and excluded subtree), but I can't say how well that >would work with real-world implementations. Obviously implementations do what implementations do (even with defined semantics), and testing would be needed to assess any residual risk from adding these kinds of constraints. -- T From thierry.moreau@connotech.com Mon Jun 11 08:59:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F8A21F862A for ; Mon, 11 Jun 2012 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZJeq4zotIPW for ; Mon, 11 Jun 2012 08:59:28 -0700 (PDT) Received: from mail.connotech.com (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0058521F8622 for ; Mon, 11 Jun 2012 08:59:27 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by mail.connotech.com (Postfix) with ESMTPA id 542F93090D; Mon, 11 Jun 2012 16:40:01 -0400 (EDT) Message-ID: <4FD61677.5030306@connotech.com> Date: Mon, 11 Jun 2012 12:01:59 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] A different question on NC... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:59:28 -0000 Miller, Timothy J. wrote: > Just to change a recent topic, if I wanted to completely prohibit a > subordinate CA from issuing a particular name type (as opposed to > restricting a name space), how would this be accomplished? IOW, if I > wanted to restrict a sub-CA from issuing certificates containing any > rfc822Name at all, what can I assert in the sub-CA cert? Quick solution ("your mileage may vary") a) let the subordinate CA establish a signature key pair b) DO NOT issue a certificate for the subordinate c) establish an automated system that c.1) receives a certificate issued by the subordinate using the above key pair c.2) validate the certificate signature c.3) validate any of your prohibitions with regard to the certificate contents c.4) if OK so far, remove subordinate signature from the certificate and apply yours (you are the CA) c.5) release the certificate The problem is who collects the money^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H The problem is being slightly off the PKI dogma that everything ends up as an certificate extension and then blame the relying party software. Regards, > > Would a critical NC with a null string in a permittedSubtrees base value > work? Something else? Not possible under the spec? Enquiring minds want > to know! :) > > Ignore implementations for the moment; theory only is fine for my current > (nefarious?) purposes. > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From david.cooper@nist.gov Mon Jun 11 09:30:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BC521F863F for ; Mon, 11 Jun 2012 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFCGcdMcifn5 for ; Mon, 11 Jun 2012 09:30:28 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8270B21F85CC for ; Mon, 11 Jun 2012 09:30:28 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Jun 2012 12:30:25 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Jun 2012 12:28:10 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q5BGUQsp019862; Mon, 11 Jun 2012 12:30:27 -0400 Message-ID: <4FD61D22.8070603@nist.gov> Date: Mon, 11 Jun 2012 12:30:26 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120609 Thunderbird/13.0 MIME-Version: 1.0 To: Thierry Moreau References: <4FD61677.5030306@connotech.com> In-Reply-To: <4FD61677.5030306@connotech.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] A different question on NC... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:30:29 -0000 You've just reinvented the registration authority! I'm not aware of any "PKI dogma" that is against the use of RAs. On 06/11/2012 12:01 PM, Thierry Moreau wrote: > Miller, Timothy J. wrote: >> Just to change a recent topic, if I wanted to completely prohibit a >> subordinate CA from issuing a particular name type (as opposed to >> restricting a name space), how would this be accomplished? IOW, if I >> wanted to restrict a sub-CA from issuing certificates containing any >> rfc822Name at all, what can I assert in the sub-CA cert? > Quick solution ("your mileage may vary") > > a) let the subordinate CA establish a signature key pair > > b) DO NOT issue a certificate for the subordinate > > c) establish an automated system that > c.1) receives a certificate issued by the subordinate using the above > key pair > c.2) validate the certificate signature > c.3) validate any of your prohibitions with regard to the certificate > contents > c.4) if OK so far, remove subordinate signature from the certificate and > apply yours (you are the CA) > c.5) release the certificate > > The problem is who collects the money^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H > > The problem is being slightly off the PKI dogma that everything ends up > as an certificate extension and then blame the relying party software. > > Regards, > >> Would a critical NC with a null string in a permittedSubtrees base value >> work? Something else? Not possible under the spec? Enquiring minds want >> to know! :) >> >> Ignore implementations for the moment; theory only is fine for my current >> (nefarious?) purposes. >> >> -- T >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > From tmiller@mitre.org Mon Jun 11 11:52:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59B21F8450 for ; Mon, 11 Jun 2012 11:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPWDACPqiOuE for ; Mon, 11 Jun 2012 11:52:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1321F843A for ; Mon, 11 Jun 2012 11:52:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9785B21B07F6; Mon, 11 Jun 2012 14:52:19 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8C5FA21B07EA; Mon, 11 Jun 2012 14:52:19 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.47]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Mon, 11 Jun 2012 14:52:19 -0400 From: "Miller, Timothy J." To: "David A. Cooper" , Thierry Moreau Thread-Topic: [pkix] A different question on NC... Thread-Index: AQHNR9kbbL/Q7VN6DEOjUsH9VgL8VZb1imyAgAAH8wD//9PQgA== Date: Mon, 11 Jun 2012 18:52:18 +0000 Message-ID: In-Reply-To: <4FD61D22.8070603@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [128.29.115.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <13763D2BC8C6DC44BEB5EF86FE038ADD@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] A different question on NC... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:52:25 -0000 On 6/11/12 11:30 AM, "David A. Cooper" wrote: >>Quick solution ("your mileage may vary") >> >> a) let the subordinate CA establish a signature key pair >> b) DO NOT issue a certificate for the subordinate >> c) establish an automated system that >> c.1) receives a certificate issued by the subordinate using the above >> key pair >> c.2) validate the certificate signature >> c.3) validate any of your prohibitions with regard to the certificate >> contents >> c.4) if OK so far, remove subordinate signature from the certificate and >> apply yours (you are the CA) >> c.5) release the certificate > You've just reinvented the registration authority! One of the problems I'm facing is I need an automated device solution (since I don't have the manpower to validate each and every device CSR) but I'm constrained by a lack of a common authentication framework. In short, I need a distributed CA function to leverage all the local authN systems, but I don't necessarily trust each of these local regions to act as CA Admins--and a CA Admin could screw the entire Enterprise (the org, not the ship :) by intentionally creating multiple types of name collisions. Re-siging and re-publishing is a concept I could work with to build an automated RA and bootstrap local authN into something the Enterprise can reasonably accept. It's certainly something to think about. -- T From wwwrun@rfc-editor.org Mon Jun 11 18:33:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6C11E809B for ; Mon, 11 Jun 2012 18:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k335qKseFA81 for ; Mon, 11 Jun 2012 18:33:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3993811E80A3 for ; Mon, 11 Jun 2012 18:33:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2456FB1E002; Mon, 11 Jun 2012 18:33:09 -0700 (PDT) To: mmyers@verisign.com, rankney@erols.com, ambarish@valicert.com, galperin@mycfo.com, cadams@entrust.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120612013309.2456FB1E002@rfc-editor.org> Date: Mon, 11 Jun 2012 18:33:09 -0700 (PDT) X-Mailman-Approved-At: Tue, 12 Jun 2012 07:16:57 -0700 Cc: pkix@ietf.org, dsb@smart.net, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC2560 (3251) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:33:15 -0000 The following errata report has been submitted for RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3251 -------------------------------------- Type: Editorial Reported by: Daniel Barclay Section: 4.2.2.2 Original Text ------------- ... They MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria: 1. ... 2. ... 3. ... Corrected Text -------------- ... They MUST reject the response if it is not the case that the certificate required to validate the signature on the response meets at least one of the following criteria: 1. ... 2. ... 3. ... Notes ----- The "fails to meet at least one ... " part of the original wording is ambiguous. It can sound like the grouping is "(fails to meet) at least one ..." rather than the (apparently) intended "fails to (meet at least one)". Note: The submitted corrected text needs further improvement. I think it eliminates the ambiguity, but it currently is harder to follow. 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. -------------------------------------- RFC2560 (draft-ietf-pkix-ocsp-07) -------------------------------------- Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Publication Date : June 1999 Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jun 11 18:39:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2F021F84B4 for ; Mon, 11 Jun 2012 18:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKoZoNMTiGAw for ; Mon, 11 Jun 2012 18:39:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0306F21F8460 for ; Mon, 11 Jun 2012 18:39:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2BFB6B1E003; Mon, 11 Jun 2012 18:39:18 -0700 (PDT) To: mmyers@verisign.com, rankney@erols.com, ambarish@valicert.com, galperin@mycfo.com, cadams@entrust.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120612013918.2BFB6B1E003@rfc-editor.org> Date: Mon, 11 Jun 2012 18:39:18 -0700 (PDT) X-Mailman-Approved-At: Tue, 12 Jun 2012 07:16:58 -0700 Cc: pkix@ietf.org, dsb@smart.net, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC2560 (3252) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:39:24 -0000 The following errata report has been submitted for RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3252 -------------------------------------- Type: Editorial Reported by: Daniel Barclay Section: 4.2.2.2.1 Original Text ------------- ... CAs issuing such a certificate should realized that a compromise of the responder's key, is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. ... Corrected Text -------------- ... CAs issuing such a certificate should realized that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. ... Notes ----- That first comma was extraneous. 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. -------------------------------------- RFC2560 (draft-ietf-pkix-ocsp-07) -------------------------------------- Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Publication Date : June 1999 Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jun 11 18:46:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6CB21F84DF for ; Mon, 11 Jun 2012 18:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OHJIbromZ5X for ; Mon, 11 Jun 2012 18:46:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DD3A821F84D8 for ; Mon, 11 Jun 2012 18:46:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 06FA9B1E002; Mon, 11 Jun 2012 18:46:22 -0700 (PDT) To: mmyers@verisign.com, rankney@erols.com, ambarish@valicert.com, galperin@mycfo.com, cadams@entrust.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120612014622.06FA9B1E002@rfc-editor.org> Date: Mon, 11 Jun 2012 18:46:22 -0700 (PDT) X-Mailman-Approved-At: Tue, 12 Jun 2012 07:16:58 -0700 Cc: pkix@ietf.org, dsb@smart.net, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC2560 (3253) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:46:28 -0000 The following errata report has been submitted for RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3253 -------------------------------------- Type: Editorial Reported by: Daniel Barclay Section: 5 Original Text ------------- For this service to be effective, certificate using systems must connect to the certificate status service provider. Corrected Text -------------- For this service to be effective, certificate-using systems must connect to the certificate status service provider. Notes ----- (Alternatively, that could be "..., systems using certificates must ..." 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. -------------------------------------- RFC2560 (draft-ietf-pkix-ocsp-07) -------------------------------------- Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Publication Date : June 1999 Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From tmiller@mitre.org Tue Jun 12 07:27:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8821F8664 for ; Tue, 12 Jun 2012 07:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jvycduc8cid for ; Tue, 12 Jun 2012 07:27:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB921F866D for ; Tue, 12 Jun 2012 07:27:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F46E21B0F83; Tue, 12 Jun 2012 10:27:15 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 59D2A21B0F4E; Tue, 12 Jun 2012 10:27:15 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.47]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 10:27:15 -0400 From: "Miller, Timothy J." To: RFC Errata System , "mmyers@verisign.com" , "rankney@erols.com" , "ambarish@valicert.com" , "galperin@mycfo.com" , "cadams@entrust.com" , "stephen.farrell@cs.tcd.ie" , "turners@ieca.com" , "kent@bbn.com" , "stefan@aaa-sec.com" Thread-Topic: [pkix] [Editorial Errata Reported] RFC2560 (3251) Thread-Index: AQHNSKYLodNVIiGvK0G43JMQhO4u5pb2rNkA Date: Tue, 12 Jun 2012 14:27:13 +0000 Message-ID: In-Reply-To: <20120612013309.2456FB1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.172.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D6246F8FAD9494184761C6060847A74@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 12 Jun 2012 10:21:13 -0700 Cc: "pkix@ietf.org" , "dsb@smart.net" Subject: Re: [pkix] [Editorial Errata Reported] RFC2560 (3251) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:27:21 -0000 I have passive voice. I suggest instead: "...The certificate required to validate the signature on the response MUST meet at least one of the following criteria: 1. ... 2. ... 3. ... """ -- T On 6/11/12 8:33 PM, "RFC Errata System" wrote: > >The following errata report has been submitted for RFC2560, >"X.509 Internet Public Key Infrastructure Online Certificate Status >Protocol - OCSP". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D2560&eid=3D3251 > >-------------------------------------- >Type: Editorial >Reported by: Daniel Barclay > >Section: 4.2.2.2 > >Original Text >------------- >... They MUST reject the response if the certificate required to validate >the signature on the response fails to meet at least one of the following >criteria: > > 1. ... > 2. ... > 3. ... > >Corrected Text >-------------- >... They MUST reject the response if it is not the case that the >certificate required to validate the signature on the response meets at >least one of the following criteria: > > 1. ... > 2. ... > 3. ... > >Notes >----- >The "fails to meet at least one ... " part of the original wording is >ambiguous. =20 > >It can sound like the grouping is "(fails to meet) at least one ..." >rather than the (apparently) intended "fails to (meet at least one)". > >Note: The submitted corrected text needs further improvement. I think >it eliminates the ambiguity, but it currently is harder to follow. > >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. > >-------------------------------------- >RFC2560 (draft-ietf-pkix-ocsp-07) >-------------------------------------- >Title : X.509 Internet Public Key Infrastructure Online >Certificate Status Protocol - OCSP >Publication Date : June 1999 >Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >Adams >Category : PROPOSED STANDARD >Source : Public-Key Infrastructure (X.509) >Area : Security >Stream : IETF >Verifying Party : IESG >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Tue Jun 12 07:29:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D24D21F8637 for ; Tue, 12 Jun 2012 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGAeStDjSkHR for ; Tue, 12 Jun 2012 07:29:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 90FF721F8552 for ; Tue, 12 Jun 2012 07:29:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2D87D21B0F69; Tue, 12 Jun 2012 10:29:21 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1374721B0F7A; Tue, 12 Jun 2012 10:29:21 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.47]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 10:29:20 -0400 From: "Miller, Timothy J." To: RFC Errata System , "mmyers@verisign.com" , "rankney@erols.com" , "ambarish@valicert.com" , "galperin@mycfo.com" , "cadams@entrust.com" , "stephen.farrell@cs.tcd.ie" , "turners@ieca.com" , "kent@bbn.com" , "stefan@aaa-sec.com" Thread-Topic: [pkix] [Editorial Errata Reported] RFC2560 (3252) Thread-Index: AQHNSKYW8b0Zp0nONUivLO3uShEGbpb2rXGA Date: Tue, 12 Jun 2012 14:29:20 +0000 Message-ID: In-Reply-To: <20120612013918.2BFB6B1E003@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.172.146] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 12 Jun 2012 10:21:15 -0700 Cc: "pkix@ietf.org" , "dsb@smart.net" Subject: Re: [pkix] [Editorial Errata Reported] RFC2560 (3252) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:29:22 -0000 > Corrected Text > -------------- > ... CAs issuing such a certificate should realized that a compromise of >the > responder's key is as serious as the compromise of a CA key used to sign > CRLs, at least for the validity period of this certificate. ... While you're at it, fix the bad tense agreement too. :) "... CAs issuing such a certificate should realize ..." -- T On 6/11/12 8:39 PM, "RFC Errata System" wrote: > >The following errata report has been submitted for RFC2560, >"X.509 Internet Public Key Infrastructure Online Certificate Status >Protocol - OCSP". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D2560&eid=3D3252 > >-------------------------------------- >Type: Editorial >Reported by: Daniel Barclay > >Section: 4.2.2.2.1 > >Original Text >------------- >... CAs issuing such a certificate should realized that a compromise of >the >responder's key, is as serious as the compromise of a CA key used to sign >CRLs, at least for the validity period of this certificate. ... > >Corrected Text >-------------- >... CAs issuing such a certificate should realized that a compromise of >the >responder's key is as serious as the compromise of a CA key used to sign >CRLs, at least for the validity period of this certificate. ... > >Notes >----- >That first comma was extraneous. > >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. > >-------------------------------------- >RFC2560 (draft-ietf-pkix-ocsp-07) >-------------------------------------- >Title : X.509 Internet Public Key Infrastructure Online >Certificate Status Protocol - OCSP >Publication Date : June 1999 >Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >Adams >Category : PROPOSED STANDARD >Source : Public-Key Infrastructure (X.509) >Area : Security >Stream : IETF >Verifying Party : IESG >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Wed Jun 13 01:08:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C6E21F869A for ; Wed, 13 Jun 2012 01:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQIP6FQtZ07z for ; Wed, 13 Jun 2012 01:08:47 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C721F869E for ; Wed, 13 Jun 2012 01:08:47 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 8CBAB18088; Wed, 13 Jun 2012 10:08:46 +0200 (CEST) To: RFC Errata System , "stefan@aaa-sec.com" , "stephen.farrell@cs.tcd.ie" , "turners@ieca.com" , Stephen Kent MIME-Version: 1.0 X-KeepSent: 2B2FA752:2ABC5FEF-C1257A1C:002C792B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 13 Jun 2012 10:08:45 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 13/06/2012 10:08:46, Serialize complete at 13/06/2012 10:08:46 Content-Type: multipart/alternative; boundary="=_alternative 002CB670C1257A1C_=" Cc: pkix@ietf.org Subject: [pkix] Tr : Re: [Editorial Errata Reported] RFC2560 (3251) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 08:08:48 -0000 Message en plusieurs parties au format MIME --=_alternative 002CB670C1257A1C_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable If we want to fix the text from RFC 2560 we cannot do it with cosmetic=20 changes,=20 like the one proposed, because the current text is wrong. The proposed way = to fix it is also wrong. In the most general case, where the OCSP response includes certificate=20 statuses from different CAs,=20 it is not possible to say that a BasicOCSPResponse is globally valid (or=20 invalid), since it depends on=20 the content of every SingleResponse. On the contrary, it is possible to=20 provide criteria to determine=20 whether a SingleResponse is or is not valid. The whole section would need to be revised. For more information, see the=20 slides I presented at the Paris meeting: http://www.ietf.org/proceedings/83/slides/slides-83-pkix-4.pdf So the question is whether we provide multiple ERRATA on many portions of=20 the document or whether we progress rfc2560bis,=20 to correct all the many errors at one time. BTW, I would like to hear the editors to know what they have been doing=20 (or not doing) since the Paris meeting=20 to progress this draft. One of the co-editors is one of our co-chairs. Denis De : "Miller, Timothy J." A : RFC Errata System ,=20 "mmyers@verisign.com" , "rankney@erols.com"=20 , "ambarish@valicert.com" ,=20 "galperin@mycfo.com" , "cadams@entrust.com"=20 , "stephen.farrell@cs.tcd.ie"=20 , "turners@ieca.com" ,=20 "kent@bbn.com" , "stefan@aaa-sec.com" Cc : "pkix@ietf.org" , "dsb@smart.net" Date : 12/06/2012 19:21 Objet : Re: [pkix] [Editorial Errata Reported] RFC2560 (3251) Envoy=E9 par : pkix-bounces@ietf.org I have passive voice. I suggest instead: "...The certificate required to validate the signature on the response MUST meet at least one of the following criteria: 1. ... 2. ... 3. ... """ -- T On 6/11/12 8:33 PM, "RFC Errata System" wrote: > >The following errata report has been submitted for RFC2560, >"X.509 Internet Public Key Infrastructure Online Certificate Status >Protocol - OCSP". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata=5Fsearch.php?rfc=3D2560&eid=3D3251 > >-------------------------------------- >Type: Editorial >Reported by: Daniel Barclay > >Section: 4.2.2.2 > >Original Text >------------- >... They MUST reject the response if the certificate required to=20 validate >the signature on the response fails to meet at least one of the following >criteria: > > 1. ... > 2. ... > 3. ... > >Corrected Text >-------------- >... They MUST reject the response if it is not the case that the >certificate required to validate the signature on the response meets at >least one of the following criteria: > > 1. ... > 2. ... > 3. ... > >Notes >----- >The "fails to meet at least one ... " part of the original wording is >ambiguous.=20 > >It can sound like the grouping is "(fails to meet) at least one ..." >rather than the (apparently) intended "fails to (meet at least one)". > >Note: The submitted corrected text needs further improvement. I think >it eliminates the ambiguity, but it currently is harder to follow. > >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. > >-------------------------------------- >RFC2560 (draft-ietf-pkix-ocsp-07) >-------------------------------------- >Title : X.509 Internet Public Key Infrastructure Online >Certificate Status Protocol - OCSP >Publication Date : June 1999 >Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >Adams >Category : PROPOSED STANDARD >Source : Public-Key Infrastructure (X.509) >Area : Security >Stream : IETF >Verifying Party : IESG >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 002CB670C1257A1C_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable If we want to fix the text from RFC 2560 we cannot do it with cosmetic changes,
like the one proposed, because the current text is wrong. The proposed way to fix it is also wrong.

In the most general case, where the OCSP response includes certificate statuses from different CAs,
it is not possible to say that a BasicOCSPResponse is globally valid (or invalid), since it depends on
the content of every SingleResponse. On the contrary, it is possible to provide criteria to determine
whether a SingleResponse is or is not valid.

The whole section would need to be revise= d. For more information, see the slides I presented at the Paris meeting:
http://www.ietf.org/proceedings/83/slides= /slides-83-pkix-4.pdf

So the question is whether we provide mul= tiple ERRATA on many portions of the document or whether we progress rfc2560bis,
to correct all the many errors at one time.

BTW, I would like to hear the editors to know what they have been doing (or not doing) since the Paris meeting
to progress this draft. One of the co-editors is one of our co-chairs.

Denis



De :     &= nbsp;  "Miller, Timothy J." <tmiller@mitre.org>
A :     &n= bsp;  RFC Errata System <rfc-e= ditor@rfc-editor.org>, "mmyers@verisign.com" <mmyers@verisign.com>, "rankney@= erols.com" <rankney@erols.com>, "ambarish@valicert.com" <ambarish@v= alicert.com>, "galperin@mycfo.com" <galperin@mycfo.com>, "cadams@ent= rust.com" <cadams@entrust.com>, "stephen.farrell@cs.tcd.ie" <steph= en.farrell@cs.tcd.ie>, "turners@ieca.com" <turners@ieca.com>, "kent@bbn.com&q= uot; <kent@bbn.com>, "stefan@aaa-sec.com" <stefan@aaa-sec.com= >
Cc :   &nb= sp;    "pkix@ietf.org&= quot; <pkix@ietf.org>, "dsb@smart.net" <dsb@smart.net>
Date :    =    12/06/2012 19:21
Objet :        Re: [pkix] [Editorial Errata Reported] RFC2560 (3251)
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



I have passive voice.  I suggest instead:

"...The certificate required to validate the signature on the response=
MUST meet at least one of the following criteria:
1. ...
2. ...
3. ...
"""

-- T



On 6/11/12 8:33 PM, "RFC Errata System" <rfc-editor@rfc-editor= .org> wrote:

>
>The following errata report has been submitted for RFC2560,
>"X.509 Internet Public Key Infrastructure Online Certificate Statu= s
>Protocol - OCSP".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errat= a=5Fsearch.php?rfc=3D2560&eid=3D3251=
>
>--------------------------------------
>Type: Editorial
>Reported by: Daniel Barclay <dsb@smart.net>
>
>Section: 4.2.2.2
>
>Original Text
>-------------
>...  They MUST reject the response if the certificate required to validate
>the signature on the response fails to meet at least one of the followi= ng
>criteria:
>
>   1. ...
>   2. ...
>   3. ...
>
>Corrected Text
>--------------
>...  They MUST reject the response if it is not the case that the
>certificate required to validate the signature on the response meets at
>least one of the following criteria:
>
>   1. ...
>   2. ...
>   3. ...
>
>Notes
>-----
>The "fails to meet at least one ... " part of the original wording is
>ambiguous.  
>
>It can sound like the grouping is "(fails to meet) at least one ..."
>rather than the (apparently) intended "fails to (meet at least one)".
>
>Note:  The submitted corrected text needs further improvement.  I think
>it eliminates the ambiguity, but it currently is harder to follow.
>
>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.
>
>--------------------------------------
>RFC2560 (draft-ietf-pkix-ocsp-07)
>--------------------------------------
>Title               : X.509 Internet Public Key Infrastructure Online
>Certificate Status Protocol - OCSP
>Publication Date    : June 1999
>Author(s)           : M. Myers, R. Ankney, A. Malpani, S. Galperin, C.
>Adams
>Category            : PROPOSED STANDARD >Source              : Public-Key Infrastructure (X.509)
>Area                : Security<= br> >Stream              : IETF
>Verifying Party     : IESG
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix=

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 002CB670C1257A1C_=-- From wwwrun@rfc-editor.org Thu Jun 14 17:52:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8211E808F for ; Thu, 14 Jun 2012 17:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlVZVRUNeWi5 for ; Thu, 14 Jun 2012 17:52:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CA06E11E8072 for ; Thu, 14 Jun 2012 17:52:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AEEA2B1E002; Thu, 14 Jun 2012 17:52:20 -0700 (PDT) To: paul.hoffman@vpnc.org, jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120615005220.AEEA2B1E002@rfc-editor.org> Date: Thu, 14 Jun 2012 17:52:20 -0700 (PDT) Cc: james.h.mannger@team.telstra.com, rfc-editor@rfc-editor.org, pkix@ietf.org Subject: [pkix] [Technical Errata Reported] RFC5912 (3259) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 00:52:38 -0000 The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3259 -------------------------------------- Type: Technical Reported by: James Manger Section: 4 Original Text ------------- CRLReason ::= INTEGER Corrected Text -------------- IMPORTS CRLReason FROM PKIX1Implicit-2009 Notes ----- CRLReason is correctly defined in section 14 "ASN.1 Module for RFC 5280, Explicit and Implicit" as: CRLReason ::= ENUMERATED { … } It is incorrectly re-defined in section 4 "ASN.1 Module for RFC 2560" (OCSP) as an INTEGER. It should import the correct definition instead. ENUMERATED and INTEGER are similar, but not the same. They are BER-encoded differently (with a tags of 0x0A and 0x02 respectively). 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. -------------------------------------- RFC5912 (draft-ietf-pkix-new-asn1-08) -------------------------------------- Title : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From James.H.Manger@team.telstra.com Thu Jun 14 20:56:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F058611E80C4 for ; Thu, 14 Jun 2012 20:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-WdeEskBrPs for ; Thu, 14 Jun 2012 20:56:14 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3466711E80B6 for ; Thu, 14 Jun 2012 20:56:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,414,1336312800"; d="scan'208";a="78217074" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 15 Jun 2012 13:56:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6742"; a="75675212" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcavi.tcif.telstra.com.au with ESMTP; 15 Jun 2012 13:56:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 15 Jun 2012 13:56:11 +1000 From: "Manger, James H" To: IETF PKIX Date: Fri, 15 Jun 2012 13:56:09 +1000 Thread-Topic: id-pkix-ocsp-nocheck extension: NULL vs empty Thread-Index: Ac1KqsxW0qeWAL8cTuuLE1CO2myLgw== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F568EA4D@WSMSG3153V.srv.dir.telstra.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 Subject: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 03:56:16 -0000 SSBoYXZlIG5vdGljZWQgc29tZSBzdHJhbmdlbHkgZW5jb2RlZCBpZC1wa2l4LW9jc3Atbm9jaGVj ayBjZXJ0aWZpY2F0ZSBleHRlbnNpb25zIHJlY2VudGx5LiBJIGV4cGVjdGVkIHRoZSBjb250ZW50 IG9mIHRoZSBleHRlbnNpb24gdG8gYmUgYSBERVItZW5jb2RlZCBOVUxMICgwNSAwMCksIGluc2lk ZSB0aGUgZXh0blZhbHVlIE9DVEVUIFNUUklORyAoMDQgMDIgMDUwMCkuIEluc3RlYWQsIGV4dG5W YWx1ZSB3YXMgYW4gZW1wdHkgT0NURVQgU1RSSU5HICgwNCAwMCkuDQoNCklzIHRoaXMgZW5jb2Rp bmcgYSBidWc/DQoNCk15IEFTTi4xIGxpYnJhcnkgYW5kIEphdmEgMS42IGZhaWwgd2l0aCB0aGVz ZSByZXNwb25kZXIgY2VydHMuIE15IGd1ZXNzIGlzIHRoYXQgbWFqb3IgYnJvd3NlcnMgYW5kIG9w ZXJhdGluZyBzeXN0ZW1zIGRvbid0IGZhaWwgKG90aGVyd2lzZSB0aGUgaXNzdWUgd291bGQgaGF2 ZSBiZWVuIGZpeGVkIGVhcmxpZXIpLg0KDQpJIGJlbGlldmUgdGhlIG9mZmVuZGluZyBjZXJ0cyBh cmUgZnJvbSBNaWNyb3NvZnQgQ0EgY29kZS4gRG9lcyBhbnlvbmUgaGF2ZSBhIE1pY3Jvc29mdCBQ S0kgY29udGFjdCB0byByZXBvcnQgdGhpcyB0ZWNobmljYWwgaXNzdWUgdG8/DQoNClRoZSByZWxl dmFudCBieXRlcyBvZiB0aGUgT0NTUCByZXNwb25kZXIgY2VydGlmaWNhdGVzIGFyZSAoREVSLWVu Y29kZWQgRXh0ZW5zaW9uKToNCg0KICAzMCAwRA0KICAgICAwNiAwOSAyQjA2MDEwNTA1MDczMDAx MDUNCiAgICAgMDQgMDANCg0KSW4gdGV4dCwgdXNpbmcgPGh0dHA6Ly9sYXBvLml0L2FzbjFqcy8+ DQoNCiBTRVFVRU5DRSgyIGVsZW0pDQogICBPQkpFQ1QgSURFTlRJRklFUiAxLjMuNi4xLjUuNS43 LjQ4LjEuNQ0KICAgT0NURVQgU1RSSU5HICgwIGJ5dGUpDQoNCkEgU3RhY2tPdmVyZmxvdyBxdWVz dGlvbiAiRXhjZXB0aW9uIFdoZW4gUmVhZGluZyBPQ1NQIFNpZ25pbmcgQ2VydHMgaW4gSmF2YSIg PCBodHRwOi8vc3RhY2tvdmVyZmxvdy5jb20vcXVlc3Rpb25zLzE0OTc1OTQvZXhjZXB0aW9uLXdo ZW4tcmVhZGluZy1vY3NwLXNpZ25pbmctY2VydHMtaW4tamF2YT4gaGFzIGEgZnVsbCBjZXJ0aWZp Y2F0ZSBzaG93aW5nIHRoaXMgcHJvYmxlbS4NCg0KW0phdmEgMS42IGZhaWxzIHRvIHBhcnNlIHRo ZXNlIGNlcnRpZmljYXRlcyAoa2V5dG9vbCAtcHJpbnRjZXJ0IC12IC1maWxlIHJlc3BvbmRlci5j ZXIpLCB0aG91Z2ggSSBiZWxpZXZlIHRoYXQgaXMgYmVjYXVzZSBvZiBhIGJ1ZyBoYW5kbGluZyB6 ZXJvLWxlbmd0aCBvY3RldCBzdHJpbmdzIHRoYXQgaXMgbm90IHNwZWNpZmljIHRvIHRoZSBpZC1w a2l4LW9jc3Atbm9jaGVjayBleHRlbnNpb24uIEphdmEgNyBzZWVtcyB0byBoYW5kbGUgdGhlc2Ug Y2VydGlmaWNhdGVzLl0NCg0KVGhlIHJlbGV2YW50IHRleHQgZnJvbSBSRkMgMjU2MCAiUEtJWCBP Q1NQIiBzZWN0aW9uIDQuMi4yLjIuMSAiUmV2b2NhdGlvbiBDaGVja2luZyBvZiBhbiBBdXRob3Jp emVkIFJlc3BvbmRlciIgaXM6DQoNCiAgIC0gQSBDQSBtYXkgc3BlY2lmeSB0aGF0IGFuIE9DU1Ag Y2xpZW50IGNhbiB0cnVzdCBhIHJlc3BvbmRlciBmb3IgdGhlDQogICBsaWZldGltZSBvZiB0aGUg cmVzcG9uZGVyJ3MgY2VydGlmaWNhdGUuIFRoZSBDQSBkb2VzIHNvIGJ5IGluY2x1ZGluZw0KICAg dGhlIGV4dGVuc2lvbiBpZC1wa2l4LW9jc3Atbm9jaGVjay4gVGhpcyBTSE9VTEQgYmUgYSBub24t Y3JpdGljYWwNCiAgIGV4dGVuc2lvbi4gVGhlIHZhbHVlIG9mIHRoZSBleHRlbnNpb24gc2hvdWxk IGJlIE5VTEwuIENBcyBpc3N1aW5nDQogICBzdWNoIGEgY2VydGlmaWNhdGUgc2hvdWxkIHJlYWxp emVkIHRoYXQgYSBjb21wcm9taXNlIG9mIHRoZQ0KICAgcmVzcG9uZGVyJ3Mga2V5LCBpcyBhcyBz ZXJpb3VzIGFzIHRoZSBjb21wcm9taXNlIG9mIGEgQ0Ega2V5IHVzZWQgdG8NCiAgIHNpZ24gQ1JM cywgYXQgbGVhc3QgZm9yIHRoZSB2YWxpZGl0eSBwZXJpb2Qgb2YgdGhpcyBjZXJ0aWZpY2F0ZS4g Q0Encw0KICAgbWF5IGNob29zZSB0byBpc3N1ZSB0aGlzIHR5cGUgb2YgY2VydGlmaWNhdGUgd2l0 aCBhIHZlcnkgc2hvcnQNCiAgIGxpZmV0aW1lIGFuZCByZW5ldyBpdCBmcmVxdWVudGx5Lg0KDQog ICBpZC1wa2l4LW9jc3Atbm9jaGVjayBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBpZC1wa2l4LW9j c3AgNSB9DQoNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= From eabalea@gmail.com Fri Jun 15 09:48:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD87F21F8559 for ; Fri, 15 Jun 2012 09:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+UoHfbIKFgo for ; Fri, 15 Jun 2012 09:48:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 118AF21F8526 for ; Fri, 15 Jun 2012 09:48:49 -0700 (PDT) Received: by yhq56 with SMTP id 56so2904534yhq.31 for ; Fri, 15 Jun 2012 09:48:48 -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 :cc:content-type; bh=EtQ2PBcpqim7MlVz9TQfyJgZ8J7Lk0WbfgaAZkMRg3k=; b=HBgtho0eNRGtCFVzTSpkUFnOHzdNJpsz5VXTRcJAxxb1EKAHZFP4Ie3Rle1DauEJ9u mCqHmK9tEQ8lzfHe8SK4AmVgmC7AMHhTz8xq8H9khWY61hASwpRMyKUNiDghlnec3c/4 XO+jcTavTbkXxV8dS02Vw+7zaa+mbiVbLu2UY831K1UE+RUYLdKRLGa78Orgo90Kzj2J oTUYDQQn/p51noPB2/N27U/KpyvKumKLSE8vbP/Ga6M7beKU/vppCshxe0G7i2DKk/O/ nGN39949UzXdPn1GMiv5X92YPDSHfCrK1NbCzRUijwQshTAjvmPTiiZmjNIkCX92kbfo 5ugw== MIME-Version: 1.0 Received: by 10.236.155.41 with SMTP id i29mr8647726yhk.115.1339778928554; Fri, 15 Jun 2012 09:48:48 -0700 (PDT) Received: by 10.236.106.103 with HTTP; Fri, 15 Jun 2012 09:48:48 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F568EA4D@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F568EA4D@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 15 Jun 2012 18:48:48 +0200 Message-ID: From: Erwann Abalea To: "Manger, James H" Content-Type: multipart/alternative; boundary=20cf303f6e821d329904c2859748 Cc: IETF PKIX Subject: Re: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:48:50 -0000 --20cf303f6e821d329904c2859748 Content-Type: text/plain; charset=UTF-8 Bonjour, The relevant RFC2560 text does show "The value of the extension should be NULL", and not "The value of the extension SHOULD be NULL". Note the capitalization. Also note that it's not written "The value of the extension MUST be NULL". Therefore, the relying party needs to be able to handle an empty content, or any other content. The content is not important in fact, that's why browsers don't fail on it. More, some of them don't care if this extension is present or not and consider the certificate to be non-revoked, whatever its real state is. 2012/6/15 Manger, James H > I have noticed some strangely encoded id-pkix-ocsp-nocheck certificate > extensions recently. I expected the content of the extension to be a > DER-encoded NULL (05 00), inside the extnValue OCTET STRING (04 02 0500). > Instead, extnValue was an empty OCTET STRING (04 00). > > -- Erwann. --20cf303f6e821d329904c2859748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

The relevant RFC2560 text does show "The value of the = extension should be NULL", and not "The value of the extension SH= OULD be NULL". Note the capitalization.
Also note that it's not= written "The value of the extension MUST be NULL".

Therefore, the relying party needs to be able to handle an empty conten= t, or any other content.

The content is not important in fact, that&= #39;s why browsers don't fail on it. More, some of them don't care = if this extension is present or not and consider the certificate to be non-= revoked, whatever its real state is.

2012/6/15 Manger, James H = <Ja= mes.H.Manger@team.telstra.com>
I have noticed some strangely encoded id-pkix-ocsp-nocheck certificate exte= nsions recently. I expected the content of the extension to be a DER-encode= d NULL (05 00), inside the extnValue OCTET STRING (04 02 0500). Instead, ex= tnValue was an empty OCTET STRING (04 00).


--
Erwann.
--20cf303f6e821d329904c2859748-- From James.H.Manger@team.telstra.com Sun Jun 17 16:28:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8C21F84FE for ; Sun, 17 Jun 2012 16:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=-1.410, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ab-fZj6FRqN for ; Sun, 17 Jun 2012 16:28:34 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6A84621F84FC for ; Sun, 17 Jun 2012 16:28:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,428,1336312800"; d="scan'208";a="83221818" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 18 Jun 2012 09:28:22 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6745"; a="70091460" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 18 Jun 2012 09:28:22 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 18 Jun 2012 09:28:21 +1000 From: "Manger, James H" To: Erwann Abalea Date: Mon, 18 Jun 2012 09:28:19 +1000 Thread-Topic: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty Thread-Index: Ac1LFr3UzYOZUlxNQdWIV5IO1nMbfwBxlKuA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F577D199@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F568EA4D@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 Cc: IETF PKIX Subject: Re: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 23:28:35 -0000 MjAxMi82LzE1IE1hbmdlciwgSmFtZXMgSCA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bT4NCj4+IEkgaGF2ZSBub3RpY2VkIHNvbWUgc3RyYW5nZWx5IGVuY29kZWQgaWQtcGtpeC1vY3Nw LW5vY2hlY2sNCj4+IGNlcnRpZmljYXRlIGV4dGVuc2lvbnMgcmVjZW50bHkuIEkgZXhwZWN0ZWQg dGhlIGNvbnRlbnQgb2YNCj4+IHRoZSBleHRlbnNpb24gdG8gYmUgYSBERVItZW5jb2RlZCBOVUxM ICgwNSAwMCksIGluc2lkZSB0aGUNCj4+IGV4dG5WYWx1ZSBPQ1RFVCBTVFJJTkcgKDA0IDAyIDA1 MDApLiBJbnN0ZWFkLCBleHRuVmFsdWUNCj4+IHdhcyBhbiBlbXB0eSBPQ1RFVCBTVFJJTkcgKDA0 IDAwKS4NCg0KDQpFcndhbm4gQWJhbGVhIHJlcGxpZWQ6DQo+IFRoZSByZWxldmFudCBSRkMyNTYw IHRleHQgZG9lcyBzaG93ICJUaGUgdmFsdWUgb2YgdGhlIGV4dGVuc2lvbg0KPiBzaG91bGQgYmUg TlVMTCIsIGFuZCBub3QgIlRoZSB2YWx1ZSBvZiB0aGUgZXh0ZW5zaW9uIFNIT1VMRCBiZSBOVUxM Ii4NCj4gTm90ZSB0aGUgY2FwaXRhbGl6YXRpb24uIEFsc28gbm90ZSB0aGF0IGl0J3Mgbm90IHdy aXR0ZW4gIlRoZSB2YWx1ZQ0KPiBvZiB0aGUgZXh0ZW5zaW9uIE1VU1QgYmUgTlVMTCIuDQo+DQo+ IFRoZXJlZm9yZSwgdGhlIHJlbHlpbmcgcGFydHkgbmVlZHMgdG8gYmUgYWJsZSB0byBoYW5kbGUg YW4gZW1wdHkNCj4gY29udGVudCwgb3IgYW55IG90aGVyIGNvbnRlbnQuDQoNCg0KSSBkaXNhZ3Jl ZSwgRXJ3YW5uLg0KDQpUaGUgZXh0blZhbHVlIGZpZWxkIGlzIGNsZWFybHkgc3BlY2lmaWVkIHRv IGhvbGQgdGhlIGVuY29kaW5nIG9mDQphbiBBU04uMSB0eXBlIGluIHRoZSB2YWx1ZSBvZiB0aGUg T0NURVQgU1RSSU5HLiBBIGVtcHR5IHN0cmluZyBpcw0Kbm90IGEgZW5jb2Rpbmcgb2YgYW55IEFT Ti4xIHR5cGUgc28gdGhlc2UgY2VydGlmaWNhdGVzIGFyZSB3cm9uZy4NCg0KWC41MDkgc2F5czoN CiAgRXh0ZW5zaW9uIDo6PSBTRVFVRU5DRSB7IA0KICAgIGV4dG5JZCAgRVhURU5TSU9OLiZpZCAo e0V4dGVuc2lvblNldH0pLCANCiAgICBjcml0aWNhbCAgQk9PTEVBTiBERUZBVUxUIEZBTFNFLCAN CiAgICBleHRuVmFsdWUgT0NURVQgU1RSSU5HIA0KICAgICAgICAgIC0tIGNvbnRhaW5zIGEgREVS IGVuY29kaW5nIG9mIGEgdmFsdWUgb2YgdHlwZSAmRXh0blR5cGUNCiAgICAgICAgICAtLSBmb3Ig dGhlIGV4dGVuc2lvbiBvYmplY3QgaWRlbnRpZmllZCBieSBleHRuSWQgLS0gfQ0KDQpSRkM1Mjgw IHNheXMgc29tZXRoaW5nIHNpbWlsYXI6DQogICAgZXh0blZhbHVlICAgT0NURVQgU1RSSU5HDQog ICAgICAgICAgLS0gY29udGFpbnMgdGhlIERFUiBlbmNvZGluZyBvZiBhbiBBU04uMSB2YWx1ZQ0K ICAgICAgICAgIC0tIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGV4dGVuc2lvbiB0eXBlIGlkZW50aWZp ZWQNCiAgICAgICAgICAtLSBieSBleHRuSUQNCg0KRWFybGllciB2ZXJzaW9ucyBkaWRuJ3QgaGF2 ZSBhIGNvbW1lbnQgaW4gdGhlIEFTTi4xIGJ1dCB3ZXJlDQpjbGVhciBlbm91Z2ggaW4gdGhlIHRl eHQuIFJGQzI0NTkgc2F5czoNCiAgIEVhY2ggZXh0ZW5zaW9uIGluY2x1ZGVzIGFuIE9JRCBhbmQg YW4gQVNOLjEgc3RydWN0dXJlLiAgV2hlbiBhbg0KICAgZXh0ZW5zaW9uIGFwcGVhcnMgaW4gYSBj ZXJ0aWZpY2F0ZSwgdGhlIE9JRCBhcHBlYXJzIGFzIHRoZSBmaWVsZA0KICAgZXh0bklEIGFuZCB0 aGUgY29ycmVzcG9uZGluZyBBU04uMSBlbmNvZGVkIHN0cnVjdHVyZSBpcyB0aGUgdmFsdWUgb2YN CiAgIHRoZSBvY3RldCBzdHJpbmcgZXh0blZhbHVlLg0KDQpSRkMyNTYwICJPQ1NQIiB3YXMgYSBi aXQgc2xvcHB5IGJlY2F1c2UgaXQgc3BlY2lmaWVkIHRoZQ0KT0lEIChpZC1wa2l4LW9jc3Atbm9j aGVjaykgYW5kIEFTTi4xIHN0cnVjdHVyZSAoTlVMTCksIGJ1dCBkaWRuJ3QNCmluY2x1ZGUgdGhl IEFTTi4xIGZvciBhbiBFWFRFTlNJT04gb2JqZWN0IGNsYXNzIGl0ZW0uDQpJdCBzaG91bGQgaGF2 ZSBpbmNsdWRlZCB0aGUgZm9sbG93aW5nOg0KDQogIG9jc3BOb0NoZWNrIEVYVEVOU0lPTiA6Oj0g ew0KICAgIFNZTlRBWCAgICAgICAgIE5VTEwNCiAgICBJREVOVElGSUVEIEJZICBpZC1wa2l4LW9j c3Atbm9jaGVjayB9DQoNClBlcmhhcHMgUkZDMjU2MGJpcyBjYW4gYWRkIHRoYXQgZm9yIGNvbXBs ZXRlbmVzcy4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From eabalea@gmail.com Mon Jun 18 08:42:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280A021F86BE for ; Mon, 18 Jun 2012 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAxTziSDH4Ub for ; Mon, 18 Jun 2012 08:42:20 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B171921F86BA for ; Mon, 18 Jun 2012 08:42:20 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4158296ghb.31 for ; Mon, 18 Jun 2012 08:42:14 -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 :cc:content-type; bh=pd+g3mGK5weeIYwGoHBgP4TvmABxJj9lZfohaHibSGA=; b=sdiZF+TmEI6drDKOW2yTeHVSPPlQOqC325q77HHO+EtW6IEUxHZXXMITzzMUn+V8Iy Y0//As//8RY8NUjQT9D40OnvVVuZZgkTrGE5o/rrV0/TseQRMC5l/2/pCm7B4VGKZTY0 UlpEvPDXac6Gbzsz7WiMkHzp35pN/PL9jcZVu7YCKn0AHl/kHHGrdEDcsZpVeB+RlM5S GCoBdhPw3OBBJ4yVtCnJGEDEg0OK7PWE3oOFEkHhs2Is4aN/Cdsc0PeBw+MC8e04eJv+ woKD63LLqinMn/yuml2V3c2mF8hSGkBmUoY2wGunaW/lLCXj+QEa+J51E0ZrxGk3S7Bh TdYQ== MIME-Version: 1.0 Received: by 10.236.155.41 with SMTP id i29mr18513419yhk.115.1340034134474; Mon, 18 Jun 2012 08:42:14 -0700 (PDT) Received: by 10.236.106.103 with HTTP; Mon, 18 Jun 2012 08:42:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F577D199@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F568EA4D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F577D199@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 18 Jun 2012 17:42:14 +0200 Message-ID: From: Erwann Abalea To: "Manger, James H" Content-Type: multipart/alternative; boundary=20cf303f6e829281d504c2c102ab Cc: IETF PKIX Subject: Re: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 15:42:22 -0000 --20cf303f6e829281d504c2c102ab Content-Type: text/plain; charset=UTF-8 Bonjour, 2012/6/18 Manger, James H > 2012/6/15 Manger, James H > >> I have noticed some strangely encoded id-pkix-ocsp-nocheck > >> certificate extensions recently. I expected the content of > >> the extension to be a DER-encoded NULL (05 00), inside the > >> extnValue OCTET STRING (04 02 0500). Instead, extnValue > >> was an empty OCTET STRING (04 00). > > Erwann Abalea replied: > > The relevant RFC2560 text does show "The value of the extension > > should be NULL", and not "The value of the extension SHOULD be NULL". > > Note the capitalization. Also note that it's not written "The value > > of the extension MUST be NULL". > > > > Therefore, the relying party needs to be able to handle an empty > > content, or any other content. > > > I disagree, Erwann. > > The extnValue field is clearly specified to hold the encoding of > an ASN.1 type in the value of the OCTET STRING. A empty string is > not a encoding of any ASN.1 type so these certificates are wrong. > Empty elements are frequently encoded in DER, think of OPTIONAL (or DEFAULT) elements. The encoding result doesn't contain them, that's all. In a sense, an empty element gets encoded into 0 octets. That's mandatory for elements whose value is equal to the specified DEFAULT value. X.509 edition 2008/11 says: Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) ENCODED BY der)} This is more or less the same as what you wrote (found in the 2005 edition), I won't argue on the phrasing. The extension value is first encoded in DER, and the result is then enclosed inside an OCTET STRING. If the DER encoding results in no output bytes, then the OCTET STRING enclosing it will have a zero length. Anyway, I got a hard time trying to read X.680 to X.683 to find an answer to the following question. Can I define my own extension like this: myStupidExample EXTENSION ::= { SYNTAX INTEGER DEFAULT 0 -- note the "DEFAULT 0" IDENTIFIED BY id-myarc-mystupidextension } The EXTENSION class is defined below: EXTENSION ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &ExtnType } WITH SYNTAX { SYNTAX &ExtnType IDENTIFIED BY &id } My understanding of X.68x is that the optionality specifier has to be included in the EXTENSION (by specifying "&ExtnType OPTIONAL" in the CLASS group, for example) and cannot be added to an object using the EXTENSION abstract class. Which of course would have the effect to render your observed extension invalid. Well. X.68x is much harder to read than X.509 and its companions together, so you may be finally right. The (good?) news is that nobody cares about the content of this extension. -- Erwann. --20cf303f6e829281d504c2c102ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

2012/6/18 Manger, James H <James.H.Manger@team.telstra.com>
2012/6/15 Manger, James H <James.H.Manger@team.telstra.com>
>> I have noticed some strangely encoded id-pkix-ocsp-nocheck
>> certificate extensions recently. I expected the content of
>> the extension to be a DER-encoded NULL (05 00), inside the
>> extnValue OCTET STRING (04 02 0500). Instead, extnValue
>> was an empty OCTET STRING (04 00).

Erwann Abalea replied:
> The relevant RFC2560 text does show "The value = of the extension
> should be NULL", and not "The value of the extension SHOULD = be NULL".
> Note the capitalization. Also note that it's not written "The= value
> of the extension MUST be NULL".
>
> Therefore, the relying party needs to be able to handle an empty
> content, or any other content.


I disagree, Erwann.

The extnValue field is clearly specified to hold the encoding of
an ASN.1 type in the value of the OCTET STRING. A empty string is
not a encoding of any ASN.1 type so these certificates are wrong.

Empty elements are frequently encoded in DER, think of OPTI= ONAL (or DEFAULT) elements. The encoding result doesn't contain them, t= hat's all. In a sense, an empty element gets encoded into 0 octets. Tha= t's mandatory for elements whose value is equal to the specified DEFAUL= T value.

X.509 edition 2008/11 says:
Extension ::=3D SEQUENCE {
=C2=A0 ext= nId EXTENSION.&id ({ExtensionSet}),
=C2=A0 critical BOOLEAN DEFAULT = FALSE,
=C2=A0 extnValue OCTET STRING
=C2=A0 (CONTAINING EXTENSION.&am= p;ExtnType({ExtensionSet}{@extnId})
=C2=A0 ENCODED BY der)}
=C2=A0
This is more or less the same as what = you wrote (found in the 2005 edition), I won't argue on the phrasing.
The extension value is first encoded in DER, and the result is then e= nclosed inside an OCTET STRING. If the DER encoding results in no output by= tes, then the OCTET STRING enclosing it will have a zero length.

Anyway, I got a hard time trying to read X.680 to X.683 to find an answ= er to the following question. Can I define my own extension like this:
<= br>myStupidExample EXTENSION ::=3D {
=C2=A0 SYNTAX INTEGER DEFAULT 0=C2= =A0 -- note the "DEFAULT 0"
=C2=A0 IDENTIFIED BY id-myarc-mystupidextension }

The EXTENSION clas= s is defined below:
EXTENSION ::=3D CLASS {
=C2=A0 &id OBJECT IDE= NTIFIER UNIQUE,
=C2=A0 &ExtnType }
WITH SYNTAX {
=C2=A0 SYNTAX= &ExtnType
=C2=A0 IDENTIFIED BY &id }

My understanding of X.68x is that the= optionality specifier has to be included in the EXTENSION (by specifying &= quot;&ExtnType OPTIONAL" in the CLASS group, for example) and cann= ot be added to an object using the EXTENSION abstract class. Which of cours= e would have the effect to render your observed extension invalid.

Well. X.68x is much harder to read than X.509 and its companions togeth= er, so you may be finally right.
The (good?) news is that nobody cares a= bout the content of this extension.

-- Erwann.
--20cf303f6e829281d504c2c102ab-- From steven.legg@enitiatives.com.au Mon Jun 18 16:56:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B97D11E80ED for ; Mon, 18 Jun 2012 16:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-oVM6kENMR9 for ; Mon, 18 Jun 2012 16:56:28 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABFDD11E809A for ; Mon, 18 Jun 2012 16:56:28 -0700 (PDT) Received: by dacx6 with SMTP id x6so7652017dac.31 for ; Mon, 18 Jun 2012 16:56:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=HQ/dE37u1NXn3hScEpbFrAPVFwQYBvnoTMcahlzadBc=; b=Caztm37T+tVESURY41VFrsUa/3CYl+7N3RP7TVDh7vq+Nr49fY9XiVa0k7OcwxbGxR kqa7bb5/PMBm8fNBzsi95gNvqak/eUmdUbi3SZ4Fm33aA9t1A6wN1mbEvN4GrUIH/x7B dv4tGdPPlkIBIudoxDG8SiP7UzQrHgVswNLhV41dvkhI1zcUx2NzQhVrSpKqJapUNZwj 1rKvlF1mf8raibd6y3rHDxOtY9y3T7GFNn1l+rHbeOplwRBmjUx7XVS92MkCCIY9rLu9 OqQC1Q44ZhanA15ziSVjMy+Zd41Xr+4chTtYQsMp7DaZuKAaVnGwu0I6ji9qGHOOP8Cw 7zqw== Received: by 10.68.239.9 with SMTP id vo9mr52207830pbc.41.1340063788276; Mon, 18 Jun 2012 16:56:28 -0700 (PDT) Received: from [192.168.1.1] (202.164.192.219.static.rev.aanet.com.au. [202.164.192.219]) by mx.google.com with ESMTPS id os9sm25570426pbb.62.2012.06.18.16.56.25 (version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 16:56:27 -0700 (PDT) Message-ID: <4FDFC026.8020008@eNitiatives.com.au> Date: Tue, 19 Jun 2012 09:56:22 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Erwann Abalea References: <255B9BB34FB7D647A506DC292726F6E114F568EA4D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F577D199@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnX/QF0UO8OY6MH0rzrukgv7vkMrfBTHG50bFgtxy6SbrrqENygypb6eac6HT+2bm0x/Q16 X-Mailman-Approved-At: Tue, 19 Jun 2012 07:14:52 -0700 Cc: IETF PKIX Subject: Re: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 23:56:29 -0000 Hi Erwann, On 19/06/2012 1:42 AM, Erwann Abalea wrote: > Bonjour, > > 2012/6/18 Manger, James H > > > 2012/6/15 Manger, James H > > >> I have noticed some strangely encoded id-pkix-ocsp-nocheck > >> certificate extensions recently. I expected the content of > >> the extension to be a DER-encoded NULL (05 00), inside the > >> extnValue OCTET STRING (04 02 0500). Instead, extnValue > >> was an empty OCTET STRING (04 00). > > Erwann Abalea replied: > > The relevant RFC2560 text does show "The value of the extension > > should be NULL", and not "The value of the extension SHOULD be NULL". > > Note the capitalization. Also note that it's not written "The value > > of the extension MUST be NULL". > > > > Therefore, the relying party needs to be able to handle an empty > > content, or any other content. > > > I disagree, Erwann. > > The extnValue field is clearly specified to hold the encoding of > an ASN.1 type in the value of the OCTET STRING. A empty string is > not a encoding of any ASN.1 type so these certificates are wrong. > > > Empty elements are frequently encoded in DER, think of OPTIONAL (or DEFAULT) elements. The encoding result > doesn't contain them, that's all. In a sense, an empty element gets encoded into 0 octets. That's mandatory > for elements whose value is equal to the specified DEFAULT value. The content of the extnValue is in no way an OPTIONAL or DEFAULT component, so it has to be the encoding of some ASN.1 value. > > X.509 edition 2008/11 says: > Extension ::= SEQUENCE { > extnId EXTENSION.&id ({ExtensionSet}), > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId}) > ENCODED BY der)} > > This is more or less the same as what you wrote (found in the 2005 edition), I won't argue on the phrasing. > > The extension value is first encoded in DER, and the result is then enclosed inside an OCTET STRING. If the > DER encoding results in no output bytes, then the OCTET STRING enclosing it will have a zero length. There is no circumstance in which the mandatory DER encoding of an ASN.1 value is a zero length sequence of octets, even though the encodings of parts of that value may be omitted. > > Anyway, I got a hard time trying to read X.680 to X.683 to find an answer to the following question. Can I > define my own extension like this: > > myStupidExample EXTENSION ::= { > SYNTAX INTEGER DEFAULT 0 -- note the "DEFAULT 0" > IDENTIFIED BY id-myarc-mystupidextension } The above is not syntactically correct, nor is there a syntactically correct way of achieving your intent. > > The EXTENSION class is defined below: > EXTENSION ::= CLASS { > &id OBJECT IDENTIFIER UNIQUE, > &ExtnType } > WITH SYNTAX { > SYNTAX &ExtnType > IDENTIFIED BY &id } > > My understanding of X.68x is that the optionality specifier has to be included in the EXTENSION (by > specifying "&ExtnType OPTIONAL" in the CLASS group, for example) and cannot be added to an object using the > EXTENSION abstract class. That is correct. The CLASS definition is analogous to a type and the myStupidExample information object is analogous to a value. Values don't have optionality specifiers. Furthermore, if the ExtnType were defined to be DEFAULT, then the default would be an ASN.1 type rather than a value. > Which of course would have the effect to render your observed extension invalid. > > Well. X.68x is much harder to read than X.509 and its companions together, so you may be finally right. James was right from the beginning :-). > The (good?) news is that nobody cares about the content of this extension. People like James and myself who use ASN.1 tools to automate the processing of ASN.1 types and values care. When people with hand-crafted encoders and decoders break the rules it spells pain for us because we have to convince our tools to behave in a non-conformant way, or work around them somehow. Regards, Steven > > -- > Erwann. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Tue Jun 19 08:04:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D83521F8604 for ; Tue, 19 Jun 2012 08:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak+x4qGFK3J3 for ; Tue, 19 Jun 2012 08:04:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A97E421F85F7 for ; Tue, 19 Jun 2012 08:04:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so5363500yhq.31 for ; Tue, 19 Jun 2012 08:04:20 -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 :cc:content-type; bh=z3hZn2IpbCvmIjxkKfHD88j2OAfCb5CdL+nHVq8raLo=; b=z2sltO1ehO3sZSOC3oD90bcC/v0SiEh+GNDfAUp1sF8jMRVBPxJzOaEMfxtz39ufSc IBE+x0+ogx5vlMH3EyiH25aRfIuanmqgUxSsKIs96YCqRR5+HFSjSoXevevsD5mzmfj7 noGorFjfSdu5jzFpMXnd/f2Nvjf1hsJH+Um8QmCGNgiwKYLlL5edbQsUyLJPh5/8exNV NIp9LYWNPbaLhAQi0GNgQEO8L9JIaw1CjFUyAilyD6i+BVoV1IvU1o7fZ5FldifbI/hk HL6vgxe74lhD/Lqeey9X1RonQtylP9apnfzWrv62yRHCFEKP69XUaD3rKy5n0bH962Ei 7csg== MIME-Version: 1.0 Received: by 10.236.176.5 with SMTP id a5mr22891739yhm.67.1340118260113; Tue, 19 Jun 2012 08:04:20 -0700 (PDT) Received: by 10.236.106.103 with HTTP; Tue, 19 Jun 2012 08:04:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Jun 2012 17:04:20 +0200 Message-ID: From: Erwann Abalea To: Peter Gutmann Content-Type: multipart/alternative; boundary=20cf302ef836d9e11404c2d4987b Cc: pkix@ietf.org Subject: Re: [pkix] id-pkix-ocsp-nocheck extension: NULL vs empty X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:04:21 -0000 --20cf302ef836d9e11404c2d4987b Content-Type: text/plain; charset=UTF-8 Bonjour Peter, 2012/6/19 Peter Gutmann > Erwann Abalea writes: > > >Empty elements are frequently encoded in DER, think of OPTIONAL (or > DEFAULT) > >elements. The encoding result doesn't contain them, that's all. In a > sense, > >an empty element gets encoded into 0 octets. That's mandatory for elements > >whose value is equal to the specified DEFAULT value. > > There's no indication in the OCSP spec that the value of noCheck is > OPTIONAL > or DEFAULT, That's the second part of my reply, trying to understand ASN.1 grammar rules. This is what I understood, and Steven confirmed it. OCSP couldn't have defined the value as OPTIONAL. The EXTENSION class hasn't defined ExtnType as OPTIONAL, so it's not (and whence, the value of the extension can't be empty). I was clearly wrong in saying that an empty OCTET STRING content is valid. I admit it. > and the fact that the NULL is given as a should rather than a > SHOULD is almost certainly a typo. If it's to be interpreted only as a > MAY as > you suggested in a previous post then that means you could put absolutely > anything in there, including the ever-popular MPEG of a cat. I doubt > that's > what the authors of the RFC had in mind. There's a typo ("should" instead of "SHOULD"), but more, there's no ASN.1 definition of the extension. As pointer by James, things would be much more clear if this was present: ocspNoCheck EXTENSION ::= { SYNTAX NULL IDENTIFIED BY id-pkix-ocsp-nocheck } That way, the value MUST be a NULL (instead of SHOULD), and it is clear that it's an extension. OCSP responders with id-pkix-ocsp-nocheck as an EKU exist. In the wild. > This is clearly a bug in Microsoft's > implementation, and it's only persisted because most other implementations > seem to ignore what the find there. > Right. Most implementations don't use a validating ASN.1 parser either. -- Erwann. --20cf302ef836d9e11404c2d4987b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour Peter,

2012/6/19 Peter Gutmann <pgut001@cs.auckland.ac.nz>
Erwann Abalea <ea= balea@gmail.com> writes:

>Empty elements are frequently encoded in DER, think of OPTIONAL (or DEF= AULT)
>elements. The encoding result doesn't contain them, that's all.= In a sense,
>an empty element gets encoded into 0 octets. That's mandatory for e= lements
>whose value is equal to the specified DEFAULT value.

There's no indication in the OCSP spec that the value of noCheck = is OPTIONAL
or DEFAULT,

That's the second part of my reply, t= rying to understand ASN.1 grammar rules. This is what I understood, and Ste= ven confirmed it.
OCSP couldn't have defined the value as OPTIONAL. = The EXTENSION class hasn't defined ExtnType as OPTIONAL, so it's no= t (and whence, the value of the extension can't be empty).

I was clearly wrong in saying that an empty OCTET STRING content is val= id. I admit it.
=C2=A0
and the fact that the NULL is given as a should rather than a
SHOULD is almost certainly a typo. =C2=A0If it's to be interpreted only= as a MAY as
you suggested in a previous post then that means you could put absolutely anything in there, including the ever-popular MPEG of a cat. =C2=A0I doubt = that's
what the authors of the RFC had in mind.

There's a= typo ("should" instead of "SHOULD"), but more, there&#= 39;s no ASN.1 definition of the extension.
As pointer by James, things w= ould be much more clear if this was present:

ocspNoCheck EXTENSION ::=3D {
=C2=A0 =C2=A0SYNTAX =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL
=C2=A0 =C2=A0IDENTIFIED BY =C2=A0id-pkix-ocsp-nocheck }

That way, t= he value MUST be a NULL (instead of SHOULD), and it is clear that it's = an extension. OCSP responders with id-pkix-ocsp-nocheck as an EKU exist. In= the wild.
=C2=A0
This is clear= ly a bug in Microsoft's
implementation, and it's only persisted because most other implementati= ons
seem to ignore what the find there.

Right. Most implementations don't use a= validating ASN.1 parser either.

--
Erwann.
--20cf302ef836d9e11404c2d4987b-- From kent@bbn.com Tue Jun 19 08:18:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA321F85D4 for ; Tue, 19 Jun 2012 08:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.719 X-Spam-Level: X-Spam-Status: No, score=-105.719 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ev0mXys3s2B for ; Tue, 19 Jun 2012 08:18:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 371FA21F85C4 for ; Tue, 19 Jun 2012 08:18:08 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49236) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sh0BN-0004LU-Bx for pkix@ietf.org; Tue, 19 Jun 2012 11:17:29 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 19 Jun 2012 11:17:34 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] new version of 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:18:08 -0000 A new version of 5280 clarifications will be published shortly. Peter Yee has taken over from David Copper as the document editor. There are very few changes since the last published version. The only major change is a new paragraph on our favorite topic of self-signed EE certs. Hopefully this text will be acceptable. Steve From turners@ieca.com Tue Jun 19 08:49:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6D711E80A4 for ; Tue, 19 Jun 2012 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvRx4I+haJaM for ; Tue, 19 Jun 2012 08:49:53 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.243.5]) by ietfa.amsl.com (Postfix) with ESMTP id A461A11E8095 for ; Tue, 19 Jun 2012 08:49:53 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 0C1FF89DBF31E; Tue, 19 Jun 2012 10:49:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id F117E89DBF2CF for ; Tue, 19 Jun 2012 10:49:52 -0500 (CDT) Received: from [96.231.119.66] (port=34597 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sh0gi-000264-NT for pkix@ietf.org; Tue, 19 Jun 2012 10:49:52 -0500 Message-ID: <4FE09FA0.7070006@ieca.com> Date: Tue, 19 Jun 2012 11:49:52 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> <4FC6775F.3070206@ieca.com> In-Reply-To: <4FC6775F.3070206@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:34597 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] draft-turner-additional-methods-4kis to ISE X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:49:56 -0000 I'm planning on asking the ISE to publish this draft in the next couple of days. Comments are welcome. spt On 5/30/12 3:39 PM, Sean Turner wrote: > I've updated this draft to remove the 224 and 384 options, added some > rationale for the extension, removed the length field (we'll rely on the > OID), and added a field to indicate the format of the output. > > spt > > On 5/30/12 3:35 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Additional Methods for Generating Key >> Identifiers and Key Identifier Semantic Extension >> Author(s) : Sean Turner >> Stephen Kent >> Filename : draft-turner-additional-methods-4kis-05.txt >> Pages : 8 >> Date : 2012-05-30 >> >> This document specifies additional methods for generating key >> identifiers from a public key. This document also specifies an >> extension to identify the algorithms used to generate the key >> identifiers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-05.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-05.txt >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >> >> _______________________________________________ >> 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 > From hallam@gmail.com Wed Jun 20 10:39:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA8821F8732 for ; Wed, 20 Jun 2012 10:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+o0SU8OAbRr for ; Wed, 20 Jun 2012 10:39:21 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 610A121F8630 for ; Wed, 20 Jun 2012 10:39:21 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6522052ggn.31 for ; Wed, 20 Jun 2012 10:39:21 -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:content-transfer-encoding; bh=bi8TrBqyXDGXH/i6EAWt7JNxY6uJrXq6NU7vjjXdnn0=; b=aORZCtUMe2TGL9/ztAUVXxwlUiwujBXXq32rOh1Q1nWY6Vi9BQqHzuus9lIBVxwvk1 8PMLYK6U6LAfTDzyL74rtVZJGArmJR9aYaujvHHc5wXpiRB8OHjF5nIVv4aaIY2+6yFY QBJM796S++isQBonZmkOUan6PHIoEMSKh1V5ey/Hh0R2WY+IxENQsPhDM9vImdqEWO7A qtv/P8dvC/DRC7Ih7VCH7G3bC/R7JzMf7NCrsx5dXYTSSVAwbQ9YHoxuvOeJOsOsQmAK Dpdsqou0FZcvJggv8fIjQqIYhxCotPEW6LpG9j8Lp95gV2lvVDgGoR/x3F8xPdNRSagl i9LQ== MIME-Version: 1.0 Received: by 10.101.165.27 with SMTP id s27mr8682303ano.8.1340213960758; Wed, 20 Jun 2012 10:39:20 -0700 (PDT) Received: by 10.236.116.68 with HTTP; Wed, 20 Jun 2012 10:39:20 -0700 (PDT) In-Reply-To: <20120602231353.GA16209@odin.ulthar.us> References: <20120602231353.GA16209@odin.ulthar.us> Date: Wed, 20 Jun 2012 13:39:20 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] WGLC X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 17:39:23 -0000 On Sat, Jun 2, 2012 at 7:13 PM, Scott Schmit wrote: > On Thu, May 31, 2012 at 02:55:35PM -0400, Stephen Kent wrote: >> Having read through the backlog of mail I see that PHB has requested >> WGLC for draft-ietf-pkix-caa-07. > > In summary: > > Terminology is used inconsistently, and in some cases new terms are > created when existing ones would do (or so it seems, as I don't fully > understand this I-D). =A0Terms are also defined unclearly, or have > examples (apparently) inconsistent with the definitions. Can you give examples? I don't know which terminology you are referring to = here. > Most of this document is unclear on first reading. Terms, formats, etc > are used before they are defined. =A0I suppose if I read this again, I > might understand it better, but I shouldn't have to. As it is, I had to > re-read many sections 2-4 times before I got to where I thought I > understood them. > > I'm especially confused about where I'm allowed/supposed to place CAA > records in the DNS, and what effect it will have if I do so (largely due > to section 3 being very unclear). I'm also unclear how binary data/value > fields are handled in presentation format. > > Most everything else I think I understood eventually. > > Now for the specifics: > > Section 1.2: > > From 2.1: >> =A0Critical =A0If set, indicates that the corresponding property entry t= ag >> =A0 =A0 MUST be understood if the semantics of the CAA record are to be >> =A0 =A0 correctly understood by the specified audience. >> >> =A0 =A0 Issuers MUST NOT issue certificates for a domain if the Extended >> =A0 =A0 Issuer Authorization Set contains unknown property entry tags th= at >> =A0 =A0 have both the Issuer and Critical bits set. > > What "Issuer" bit/flag? There is no such bit/flag defined. Ah, this seems to be an artifact of having removed the issuer flag. Suggest the following instead. Critical If set, indicates that the corresponding property entry tag MUST be understood if the semantics of the CAA record are to be correctly interpreted. Issuers MUST NOT issue certificates for a domain if the Extended Issuer Authorization Set contains unknown property entry tags that have the Critical bit set. >> =A0The following properties are defined: >> >> =A0issue [; ]* =A0The issue property entry >> =A0 =A0 declares an authorization entry granting authorization to issue = to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^ >> =A0 =A0 the holder of the specified domain name or a party acting under >> =A0 =A0 the express written authority of the holder of the domain name. > > ... > >> =A0The following example informs CAs that certificates MUST NOT be >> =A0issued except by the holder of the domain name 'ca.example.net' or an > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^ >> =A0authorized agent thereof. =A0Since the policy is published at the >> =A0Public Delegation Point, the policy applies to all subordinate >> =A0domains under example.com. I don't see any inconsistency. In both cases the text appears to me to read the same. In the first case the text refers to an access control entry and so is a GRANT of a right, in the second the text refers to an ACL and so describes an exclusive right. >> =A0$ORIGIN example.com >> =A0. =A0 =A0 =A0 CAA 0 issue "ca.example.net" > > This appears to contradictory. > > I'm guessing that the latter is correct, and the "specified domain name" > in the earlier paragraph isn't referring to the "" field. > > It should probably be "issue " and the following text > should clarify between the CA domain name and the domain that the record > is for. Does this make it clearer? The issue property entry declares an authorization entry granting authorization to issue to the holder of the domain name or a party acting under the express written authority of the holder of that domain = name. > I'm not sure I like that examples of CAA RRs are provided before the > syntax of the CAA record has actually been defined--it's making this > very hard to understand. I think I have used that particular approach in pretty much every spec I have written in the past ten years. I find that the majority of readers work from the examples rather than the syntax. This is particularly common in W3C and OASIS specs where the sections tend to be marked as normative or non-normative. > The definition for Public Delegation Point is unhelpful to me. What's a > "Top Level Directory"? Is this a TLD? (TLD expands to Top-Level Domain, > not Directory). Apparently not, since example.com isn't a TLD, so what > is it? =A0How does an issuer know if a given domain is a registry/public > delegation point or not? If you mean to say that parent domains can set > CAA records for their subdomains, just say so--don't invent new terms > for it. That is a well known term of art that a CA is already required to track in their practices. A public delegation point is NOT a TLD because many CC TLDs delegate from SLDs e.g. '.co.uk' > Honestly, the document is a mess of terminology and jargon. > > In section 2.1, we have "property entries", "flags", "properties", and > "tag-value pairs". =A0In section 3, we also have "[CAA] Authorization > Entry", "Extended Issuer Authorization Set", and "Issuer Authorization > Set", etc which are defined, but not in the same terms as in section > 2.1. =A0They seem to overlap in meaning with the terms in section 2.1, bu= t > might not. I don't know. > > Section 3: > > The definition of Extended Issuer Authorization Set (EIAS) is > unnecessarily complex. The definition in 1.2 implies that my parent > domain (or PDP) can set CAA records that apply to me (otherwise the > "extended" terminology doesn't make any sense) but a straightforward > reading of the definition in this section says that CAA records can only > be set on domains immediately below a TLD (or a CCTLD SLD). (I think > that's what you mean by PDP.) > > That's conveniently the same set of entities that public CAs will issue > certificates for (AFAICT)--domains with entries in a whois database. > > So why all this convoluted terminology & indirection for determining if > a CAA record is valid or not when what it really comes down to is "CAA > records on the domain that an issuer is willing to consider issuing > certs for"? Or if you don't want to be that loose about it for some > reason, then say "CAA records are only valid on domains delegated to by > registries". That should save at least a page of text. Because several parties pointed out that they have a need to apply specific controls to particular subdomains. > But your example in section 3 implies I've misread again, because > according to your rules, caa.example.com's EIAS is empty, but your > example claims otherwise. I'll let someone explain where I misparsed. Ah, there is a bug here, 'is empty' should have been 'is not empty'. If the Issuer Authorization Set for the domain is not empty, the Extended I= ssuer Authorization Set is the Issuer Authorization Set for the domain. If the immediately superior node in the DNS hierarchy is a Public Delegatio= n Point, the Extended Issuer Authorization Set is empty. Otherwise the Extended Issuer Authorization Set is that of the immediately superior node in the DNS hierarchy. > Section 3.1 > > You went through the trouble of defining canonical names abstractly (I > thought to make it possible to handle future BNAME, SHADOW, or whatever > records in the future), but then explicitly call out CNAME and DNAME > here. If a future BNAME comes about, there is no requirement to process > such records correctly. Therefore you don't need the definitions in 1.2. I don't see the logic there. If BNAME is added, so what? It is not going to replace CNAME or DNAME in our life times. The CAA spec cannot require CAs to process DNS records that have yet to be invented. An issuer MUST perform CNAME and DNAME processing as defined in the DNS specifications [RFC1035] to resolve CAA records. > Section 4.1: > > I think you're mixing up "tag value pairs" and "properties" compared to > the discussion of this in section 2.1--the syntax shown there allow > there to be zero or more tag-value pairs. =A0However, the first sentence > here say that there is only one per RR. In 2.1-speak, you have one > property per RR. > >> =A0+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-| >> =A0| Flags =A0 =A0 =A0 =A0 =A0| Tag Length =3D n | >> =A0+----------------+----------------+...+---------------+ >> =A0| Tag char 0 =A0 =A0 | Tag Char 1 =A0 =A0 |...| Tag Char n-1 =A0| >> =A0+----------------+----------------+...+---------------+ >> =A0+----------------+----------------+.....+---------------+ >> =A0| Data byte 0 =A0 =A0| Data byte 1 =A0 =A0|.....| Data byte m-1 | >> =A0+----------------+----------------+.....+---------------+ > > The formatting of the wire format causes me to overlook the flags & tag > length fields. Even when I know they're there, I still tend to ignore > them. > >> =A0Where n is the length specified in the tag length field and m is the >> =A0remaining octets in the data field (m =3D d - n - 2) where d is the >> =A0length of the data section. > > d is never used in the figure. What is "the length of the data section"? > Is it the size of the RDATA (RDLENGTH) or the number of data bytes? > Assuming your equation is right, it's the former. Where n is the length specified in the tag length field and m is the remaining octets in the data field (m =3D d - n - 2) where d is the length of the RDATA section. > I'd recommend a presentation more like what's shown in RFC 1035: > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 = =A01 =A01 =A01 =A01 =A01 >> =A0 =A0 0 =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A08 =A09 =A00 =A01 =A02 = =A03 =A04 =A05 >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 / >> =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 / >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TYPE =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CLASS =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 | >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TTL =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RDLENGTH =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| >> =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RDATA =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 / >> =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 / >> =A0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > (Especially since your RRtype is mostly variable-length fields.) I have always found those confusing because they suggest to me that the data sections are aligned on word or quadword boundaries. ASCII art is a bad way to present data. > The critical flag is called Issuer Critical Flag here, but just > "Critical [Flag]" in section 2.1. OK, will make it issuer criticality in both places. >> =A0Tag =A0The property identifier, a sequence of ASCII characters. >> >> =A0 =A0 Tag values MAY contain ASCII characters a through z and the >> =A0 =A0 numbers 0 through 9. =A0Tag values MUST NOT contain any other >> =A0 =A0 characters. =A0Matching of tag values is case insensitive. > > Are you sure you don't want to include dashes? What if you want to > define a tag with multiple words in it in the future? I guess you could > just do camelcase. The properties have to fit in the DNS which is pretty much constrained to 500 bytes. So I don't see much call for enormous tags. I did think of putting dashes in but the code for various DNS servers persuaded me that was probably not a good plan. >> =A0Tag Length =A0A single octet containing an unsigned integer specifyin= g >> =A0 =A0 the tag length in octets. =A0The tag length MUST be at least 1 a= nd >> =A0 =A0 SHOULD be no more than 15. > > Making the max tag length a SHOULD seems useless to me. =A0If I'm > implementing software that parses the RR (but doesn't process it), I > must assume that the tag length could be 255, or I'll break if another > CAA specification comes out that creates a tag > 15 bytes long. =A0If I'm > processing the record, I could ignore CAA records with tag lengths not > equal to the lengths of any tags I recognize (I won't be able to process > the records anyway), but then the limitation on tag length doesn't > really help me out either. The reason for the SHOULD is just to try to persuade folk not to bloat the tag and make the records unnecessarily long. It is a performance issue and hence a SHOULD is appropriate. >> =A0Value =A0A sequence of octets representing the property value. >> =A0 =A0 Property values are encoded as binary values and MAY employ sub- >> =A0 =A0 formats. > > Ok, so above, in your wire format, there is nothing labeled "Value" or > even "Value byte". Below, in your presentation format, there is no > "Value" either--just data. I will change the diagram to read Value so that then there is no confusion between Data and RDATA. > Section 4.1.1: > Again, "tag" isn't defined consistently with section 2.1. > > Assuming that data =3D "Value" above, data can be a binary field. > >> =A0CAA > ... >> =A0data =A0Is the ascii text Encoding of the value field > > What does "ascii text Encoding of the value field" mean? Does that mean > that it'll be one of "US-ASCII", "UTF-8", etc? If so, where does the > value go? =A0If data =3D Value, then since Value can be binary data, what > encoding is it? =A0That either means (to me) that non-printable character= s > aren't allowed or that there's some kind of encoding of the binary data > into printable ascii that's required, but that encoding isn't defined. ASCII to me means ASCII which would imply to me NOT UNICODE. I changed it to US-ASCII Here there is a divergence between the code and the spec. My patch for BIND allows records to use binary field values and we use this for certificate hashes and such. But these properties are not specified in the spec and in fact our only records we have spec for are ascii records and I am tending to think we might end up going all ascii. > Section 4.2: > > Underscores aren't legal in domain names. Is there an existing ABNF > production for a domain name that you could use instead (in case the set > is expanded later?) You should also probably specify that this is in > A-label form. > >> =A0value =3D *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE > > "|" isn't a legal ABNF operator. Also, DQUOTE is included by VCHAR. =A0Fo= r > the record, how do quotes needed to delimit the data field of a CAA > record presentation format interact with quotes in a parameter value? Is > that worth allowing quotes in a value? > > (Again, you've mixed up "tag" and "property" and "value" throughout the > document, making the prior sentence ambiguous.) > > By the way, how should issuers process malformed CAA records? Ignore > them? Not issue? > > What's an "issuer-parameter"? > > Section 5: > > I debate the correctness of the last paragraph -- if Google had > published CAA records, DigiNotar would still have issued those certs. If DigiNotar had processed anything correctly they wouldn't have issued any certs at all: > Section 5.2: > > If the record is signed, bogus records had better be ignored. That > needs to be added as a requirement in section 3.2 -- if DNSSEC is used, > the record MUST not be bogus (ditto for denial of existence). =A0Oh, I se= e > that you say that in 5.2.1, but that probably is better placed in 3.2. > > I realize this section is ignoring DNSSEC, but it should be clear that > this only applies for insecure domains. There is no need for the subsection, I merged 5.2 and 5.2.1 > Section 5.2.1: > > You say that lookup SHOULD be via authoritative servers, but then that > you MUST NOT use cached data. Which is it? > > What additional anti-spoofing or anti-suppression controls are you > referring to? Not looking for an exhaustive list, but some examples > would be nice. In cases where DNSSEC is not deployed in a corresponding domain, a CA SHOULD attempt to mitigate this risk by employing appropriate DNS security controls. For example all portions of the DNS lookup process SHOULD be performed against the authoritative name server. Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls. > Section 5.3: > > A CAA record can be malformed and yet secure. What are issuers supposed > to do? Manual exception processing - tell the customer to fix their DNS before they can get a cert. Should probably add a section to mention this. > Section 6.1/6.2: > > You don't label the first column. Which makes your direction to IANA > about how to add to the registry ambiguous--especially in light of > inconsistent wording. > > I hope this helps. Thanks, I will print out the current edit copy and then go through and audit the tag/property issue. --=20 Website: http://hallambaker.com/ From i.grok@comcast.net Wed Jun 20 22:16:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911C21F8534 for ; Wed, 20 Jun 2012 22:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o24i7F+iLKya for ; Wed, 20 Jun 2012 22:16:09 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C684521F8533 for ; Wed, 20 Jun 2012 22:16:08 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id Qt0D1j0020EZKEL51tG8Jq; Thu, 21 Jun 2012 05:16:08 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta01.westchester.pa.mail.comcast.net with comcast id QtG61j0092Ekl483MtG8L9; Thu, 21 Jun 2012 05:16:08 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q5L5G5oP030860 for ; Thu, 21 Jun 2012 01:16:05 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q5L5G5R7030859 for pkix@ietf.org; Thu, 21 Jun 2012 01:16:05 -0400 Date: Thu, 21 Jun 2012 01:16:05 -0400 From: Scott Schmit To: pkix@ietf.org Message-ID: <20120621051605.GA6775@odin.ulthar.us> Mail-Followup-To: pkix@ietf.org References: <20120602231353.GA16209@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] WGLC X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 05:16:10 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 20, 2012 at 01:39:20PM -0400, Phillip Hallam-Baker wrote: > On Sat, Jun 2, 2012 at 7:13 PM, Scott Schmit wrote: > > Now for the specifics: > > > Critical >=20 > If set, indicates that the corresponding property entry tag MUST be > understood if > the semantics of the CAA record are to be correctly interpreted. >=20 > Issuers MUST NOT issue certificates for a domain if the Extended Issuer > Authorization Set contains unknown property entry tags that have the > Critical bit set. That works. > Does this make it clearer? >=20 > The issue property entry declares an authorization entry granting > authorization to issue to the holder of the domain name > or a party acting under the express written authority of the holder of > that domain name. Not really. The problem is that I can read that two ways: =3D the domain held by the entity inserting this record into the DNS i.e., "The issue property entry is an ACL allowing an unnamed issuer to issue a certificate with subject to " or =3D the domain held by/associated with the entity processing this record i.e., "The issue property entry is an ACL allowing an issuer that owns to issue certificates with subject to " Granted, the latter is the only one that makes sense, but my brain went straight to the former and assumed there was something wrong with your text. Since I'm not an issuer, I read this spec as about how a holder of a domain name can protect the integrity of the domain with the cooperation of issuers, not as a spec for issuers where the holder of the domain name is a third party. It's both, of course, but if you're not an issuer, you'll probably read it the former way. Hence my suggestion that you be more specific about whose domain you're talking about in the template text. Your text seems like an overly-complex way of saying: The issue property entry authorizes an issuer identified by (or a party acting under the authority of that issuer) to issue a certificate to the holder of the domain name. > > I'm not sure I like that examples of CAA RRs are provided before the > > syntax of the CAA record has actually been defined--it's making this > > very hard to understand. >=20 > I think I have used that particular approach in pretty much every spec > I have written in the past ten years. I find that the majority of > readers work from the examples rather than the syntax. This is > particularly common in W3C and OASIS specs where the sections tend to > be marked as normative or non-normative. Ok, but keep in mind that if you've never seen this spec before, you don't know anything about the number in the example. I felt that I was led to believe that the prior property definitions were the entirety of the record format. You do explain the critical flag, but the way you described it, it sounds like it's specified in the [; ]* part of the syntax. ("...tagged with...") So, when I saw the example, I didn't know what the number is for, which called into question whether I understand the syntax at all, and how much else I didn't know about this new RR type. Hence my feeling that the example hurt more than it helped. The easy way to fix this is to explain that every record starts with a number representing the flags that are set, if any, followed by the property entry. (And be careful about how you use the word "tag".) > > The definition for Public Delegation Point is unhelpful to me. What's a > > "Top Level Directory"? Is this a TLD? (TLD expands to Top-Level Domain, > > not Directory). Apparently not, since example.com isn't a TLD, so what > > is it? =A0How does an issuer know if a given domain is a registry/public > > delegation point or not? If you mean to say that parent domains can set > > CAA records for their subdomains, just say so--don't invent new terms > > for it. >=20 > That is a well known term of art that a CA is already required to > track in their practices. A public delegation point is NOT a TLD > because many CC TLDs delegate from SLDs e.g. '.co.uk' Ok, now I understand, but if it's well-known, it's not very well-used where Google can see it. A google search for '"public delegation point" dns' only gets hits for your draft and discussions of it. "Public Suffix" seems to be a much more widespread name, just going by the Google search results for that term. See https://en.wikipedia.org/wiki/Public_Suffix_List. Apparently "effective TLD" is also used. http://publicsuffix.org/list/ might not be a bad informative reference, just in case someone is looking for an authoritative list. I'd also suggest that in the definition, you say something like: "such as .com or .co.uk" and NOT use example.com as an example of one later (though you may be able to avoid specific examples using the reference above). > > So why all this convoluted terminology & indirection for determining if > > a CAA record is valid or not when what it really comes down to is "CAA > > records on the domain that an issuer is willing to consider issuing > > certs for"? Or if you don't want to be that loose about it for some > > reason, then say "CAA records are only valid on domains delegated to by > > registries". That should save at least a page of text. >=20 > Because several parties pointed out that they have a need to apply > specific controls to particular subdomains. Ok, I'll have to re-look at this when I have more time available, but in the meantime I'd strongly suggest coming up with a way of defining how to use a CAA record without inventing new terms like "Extended Issuer Authorization Set" -- I'm not convinced you need to, and it really hurts readability. > > Section 3.1 > > > > You went through the trouble of defining canonical names abstractly (I > > thought to make it possible to handle future BNAME, SHADOW, or whatever > > records in the future), but then explicitly call out CNAME and DNAME > > here. If a future BNAME comes about, there is no requirement to process > > such records correctly. Therefore you don't need the definitions in 1.2. >=20 > I don't see the logic there. If BNAME is added, so what? It is not > going to replace CNAME or DNAME in our life times. My logic is that you go out of your way to define canonical domain name, etc in a more abstract sense and then never use it in an abstract sense. If your readers are expected to know what CNAMEs and DNAMEs are (and that makes perfect sense to me), you don't need to redefine that for them. > > I'd recommend a presentation more like what's shown in RFC 1035: > > (Especially since your RRtype is mostly variable-length fields.) >=20 > I have always found those confusing because they suggest to me that > the data sections are aligned on word or quadword boundaries. Fair enough, but your existing example implies an alignment but then breaks it, leaving it a little unclear what you intended. This works better, IMHO: =A0 0 =A01 =A02 =A03 =A04 =A05 =A06 =A07 +--+--+--+--+--+--+--+--+ | =A0 =A0 Flags =A0 =A0 =A0 =A0 =A0 =A0 | +--+--+--+--+--+--+--+--+ | =A0 =A0 Tag Length=A0 =A0 =A0 =A0 | +--+--+--+--+--+--+--+--+ / =A0 =A0 Tag =A0 =A0 =A0 =A0 =A0 =A0 / / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / +--+--+--+--+--+--+--+--+ / =A0 =A0 Value =A0 =A0 =A0 =A0 =A0 / / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / +--+--+--+--+--+--+--+--+ That implies no alignment, but clarifies that some parts are variable-length. > >> =A0Tag =A0The property identifier, a sequence of ASCII characters. > >> > >> =A0 =A0 Tag values MAY contain ASCII characters a through z and the > >> =A0 =A0 numbers 0 through 9. =A0Tag values MUST NOT contain any other > >> =A0 =A0 characters. =A0Matching of tag values is case insensitive. > > > > Are you sure you don't want to include dashes? What if you want to > > define a tag with multiple words in it in the future? I guess you could > > just do camelcase. >=20 > The properties have to fit in the DNS which is pretty much constrained > to 500 bytes. So I don't see much call for enormous tags. Ok, that makes sense. Probably wouldn't hurt to state that as rationale for the SHOULD (it wasn't obvious to me). > I did think of putting dashes in but the code for various DNS servers > persuaded me that was probably not a good plan. Oh, I didn't think of that. That said, you could always pave the way for others... That, and it shouldn't be *that* hard to factor out the "parse LDH" code from "parse domain name." But it's a reasonable choice, I just thought I'd point out alternatives that might help later. By the way, I just noticed that section 4.1 says that "tag values" (tags?) are case-insensitive, but section 4.1.1 says that tags are lower-case. > The reason for the SHOULD is just to try to persuade folk not to bloat > the tag and make the records unnecessarily long. It is a performance > issue and hence a SHOULD is appropriate. I'd recommend that you put that rationale in the document so that future spec-writers understand the rationale. > I will change the diagram to read Value so that then there is no > confusion between Data and RDATA. Sounds good. > ASCII to me means ASCII which would imply to me NOT UNICODE. I changed > it to US-ASCII Sorry, my brain translated that to "text" -- too used to sloppy language at work. US-ASCII should override my autocorrect nicely. :) > Here there is a divergence between the code and the spec. >=20 > My patch for BIND allows records to use binary field values and we use > this for certificate hashes and such. But these properties are not > specified in the spec and in fact our only records we have spec for > are ascii records and I am tending to think we might end up going all > ascii. That's probably for the best--otherwise you need to specify how to tell straight text apart from encoded binary (and how the binary is encoded). That just makes things more complicated for little gain, IMHO. (You can always define a specific tag's value to be a BASE64 encoding of a binary value if there's a compelling need for transmission of binary data--it won't be quite as efficient, but it'll be unambiguous). > > I debate the correctness of the last paragraph -- if Google had > > published CAA records, DigiNotar would still have issued those certs. >=20 > If DigiNotar had processed anything correctly they wouldn't have > issued any certs at all: Just saying that you're slightly overselling CAA here. > In cases where DNSSEC is not deployed in a corresponding domain, a CA > SHOULD attempt to mitigate this risk by employing appropriate DNS > security controls. For example all portions of the DNS lookup process > SHOULD be performed against the authoritative name server. Data > cached by third parties MUST NOT be relied on but MAY be used to > support additional anti-spoofing or anti-suppression controls. That works. > > Section 5.3: > > > > A CAA record can be malformed and yet secure. What are issuers supposed > > to do? >=20 > Manual exception processing - tell the customer to fix their DNS > before they can get a cert. >=20 > Should probably add a section to mention this. Agreed. --=20 Scott Schmit --IS0zKkzwUGydFO0o Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNjIxMDUxNjA1WjAjBgkqhkiG9w0BCQQxFgQUZGb1hOmC F9W92CUMCspw8GCHlqwweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAePQFV/E2 OVsJb0x50NqIEdqWhtY8TSqx1hP2X9HubWxh7HCRpnaNBe2STwIPS89rgBFvu0xJ2s5yqcxs LaramfkDY13DYFmzBfNPTo9fEw57L+eK6vbnlpeX9Tx3zeIZXyHExVHu65UTrtV3yAFyQQul 9nv5+tXTa19daiLrZutULamtEygcOwKOxzdj7Opcl9vTggpJB44kICfWehhvd/FVimLgnpbU yvhiuqXHBp0RNr0S7pwDN5bCrLsDL16rq66efYlrWglKsWT6jgHSP0tV9q3BZrtTyhZYUtpl aXSZpPIvi8aByncpP+INyotrbKPFrcH76A5P+MtLWCZLbg== --IS0zKkzwUGydFO0o-- From James.H.Manger@team.telstra.com Thu Jun 21 00:22:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC121F84A6 for ; Thu, 21 Jun 2012 00:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn4X9j9bAV0F for ; Thu, 21 Jun 2012 00:22:52 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0C95321F8496 for ; Thu, 21 Jun 2012 00:22:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,449,1336312800"; d="scan'208";a="77835060" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 21 Jun 2012 17:22:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6748"; a="19908120" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcani.tcif.telstra.com.au with ESMTP; 21 Jun 2012 17:22:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Thu, 21 Jun 2012 17:22:47 +1000 From: "Manger, James H" To: Sean Turner , "pkix@ietf.org" Date: Thu, 21 Jun 2012 17:22:46 +1000 Thread-Topic: [pkix] draft-turner-additional-methods-4kis to ISE Thread-Index: Ac1OMzJPhZo5okOLTcy+864Dp9z/bABQa4zw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F593B71D@WSMSG3153V.srv.dir.telstra.com> References: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> <4FC6775F.3070206@ieca.com> <4FE09FA0.7070006@ieca.com> In-Reply-To: <4FE09FA0.7070006@ieca.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 Subject: Re: [pkix] draft-turner-additional-methods-4kis to ISE X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 07:22:53 -0000 QSBmZXcgY29tbWVudHMgb24gIkFkZGl0aW9uYWwgbWV0aG9kcyBmb3Iga2V5IGlkZW50aWZpZXJz IjoNCg0KDQpUcnVuY2F0aW9uOiBhcmUgdGhlICJsZWFzdCBzaWduaWZpY2FudCBiaXRzIiBvZiBh IGhhc2ggdGhlIHJpZ2h0LW1vc3QgYml0cz8gSSB3b3VsZCBoYXZlIHRob3VnaCBrZWVwaW5nIHRo ZSBsZWZ0bW9zdCBiaXRzIHdhcyBzbGlnaHRseSBtb3JlIGludHVpdGl2ZS4NCg0KSSB0aGluayB3 ZSBiZXR0ZXIgcHV0IGFuIGV4YW1wbGUgaW4gdGhlIGRyYWZ0OiBhIFN1YmplY3RQdWJsaWNLZXlW YWx1ZTsgMiAob3IgNCkgc3ViamVjdEtleUlkIGV4dGVuc2lvbiB2YWx1ZXM7IGFuZCAyIChvciA0 KSBjb3JyZXNwb25kaW5nIGV4dC1za2lTZW1hbnRpY3MgdmFsdWVzLg0KDQoNClRoZSBleHQtc2tp U2VtYW50aWNzIGV4dGVuc2lvbiB3b3VsZCBiZSBiZXR0ZXIgaWYgaXQgaGVsZCBhIHNpbmdsZSBB bGdvcml0aG1JZGVudGlmaWVyIC0tIGlkZW50aWZ5aW5nIHRoZSBhbGdvcml0aG0gdXNlZCB0byBn ZW5lcmF0ZSB0aGUgc3ViamVjdCBrZXkgaWQuIFRoZW4gdGhlIHNwZWMgY2FuIGRlZmluZSB0d28g c3VjaCBhbGdvcml0aG1zLiANCg0KICBleHQtc2tpU2VtYW50aWNzIEVYVEVOU0lPTiA6Oj0gew0K ICAgIFNZTlRBWCBBbGdvcml0aG1JZGVudGlmaWVyDQogICAgSURFTlRJRklFRCBCWSBpZC1wZS1z a2lTZW1hbnRpY3MgfQ0KDQogIGFsZy1rZXlIYXNoIEFMR09SSVRITSA6Oj0geyBBbGdvcml0aG1J ZGVudGlmaWVyIElERU5USUZJRVIgaWQta2V5SGFzaCB9DQoNCiAgYWxnLWtleUluZm9IYXNoIEFM R09SSVRITSA6Oj0geyBBbGdvcml0aG1JZGVudGlmaWVyIElERU5USUZJRVIgaWQta2V5SW5mb0hh c2ggfQ0KDQogIGFsZy1rZXlIYXNoIGluZGljYXRlcyB0aGF0IHRoZSBrZXkgaWQgaXMgdGhlLCBw b3NzaWJseSB0cnVuY2F0ZWQsIGhhc2ggb2YNCiAgdGhlIHZhbHVlIG9mIHRoZSBCSVQgU1RSSU5H IHN1YmplY3RQdWJsaWNLZXkgKGV4Y2x1ZGluZyB0aGUgdGFnLCBsZW5ndGgsDQogIGFuZCBudW1i ZXIgb2YgdW51c2VkIGJpdHMpLiBUaGUgYW1vdW50IG9mIHRydW5jYXRpb24gY2FuIGJlIGRldGVy bWluZWQgZnJvbSB0aGUNCiAgbGVuZ3RoIG9mIHRoZSBhY3R1YWwga2V5IGlkZW50aWZpZXIuIFRy dW5jYXRpb24ga2VlcHMgdGhlIGxlYXN0IHNpZ25pZmljYW50IGJpdHMNCiAgb2YgdGhlIGhhc2gu IFRoZSByZXF1aXJlZCBwYXJhbWV0ZXIgb2YgdGhpcyBhbGdvcml0aG0gaWRlbnRpZmllcyB0aGUg aGFzaA0KICBhbGdvcml0aG0gdGhhdCBpcyB1c2VkLg0KDQogIGFsZy1rZXlJbmZvSGFzaCBkaWZm ZXJzIGZyb20gYWxnLWtleUhhc2ggaW4gdGhhdCB0aGUgaGFzaCBjb3ZlcnMgdGhlDQogIGtleSBh bGdvcml0aG0gaWQgaW4gYWRkaXRpb24gdG8gdGhlIGFjdHVhbCBwdWJsaWMga2V5LiAgYWxnLWtl eUluZm9IYXNoDQogIGluZGljYXRlcyB0aGF0IHRoZSBrZXkgaWQgaXMgdGhlLCBwb3NzaWJseSB0 cnVuY2F0ZWQsIGhhc2ggb2YgdGhlDQogIHN1YmplY3RQdWJsaWNLZXlJbmZvIGZpZWxkLiBUaGUg YW1vdW50IG9mIHRydW5jYXRpb24gY2FuIGJlIGRldGVybWluZWQgZnJvbSB0aGUNCiAgYWN0dWFs IGtleSBpZGVudGlmaWVyIHZhbHVlLiBUcnVuY2F0aW9uIGtlZXBzIHRoZSBsZWFzdCBzaWduaWZp Y2FudCBiaXRzDQogIG9mIHRoZSBoYXNoLiBUaGUgcmVxdWlyZWQgcGFyYW1ldGVyIG9mIHRoaXMg YWxnb3JpdGhtIGlkZW50aWZpZXMgdGhlIGhhc2gNCiAgYWxnb3JpdGhtIHRoYXQgaXMgdXNlZC4N Cg0KDQoNCklmIHRoZSBzcGVjIGlzIGdvaW5nIHRvIGRlZmluZSBhbGcta2V5SW5mb0hhc2ggKHdo aWNoIGl0IGN1cnJlbnRseSBkb2VzIHVuZGVyDQp0aGUgbmFtZSBpZC1zdWJqZWN0UHVibGljS2V5 SW5mbykgZm9yIHRoZSBleHRlbnNpb24gKHNlY3Rpb24gMykgaXQgcmVhbGx5IG5lZWRzDQp0byBk ZWZpbmUgaXQgYXMgYWRkaXRpb25hbCBtZXRob2RzIGZvciBnZW5lcmF0aW5nIGtleSBpZHMgKHNl Y3Rpb24gMikuDQoNCg0KVGhlIGN1cnJlbnQgbW9kZWwgb2YgdGhlIGV4dGVuc2lvbiBjb25zaXN0 cyBvZiBhIGhhc2ggYWxnb3JpdGhtLCBhbiBpbnB1dCBpZCwgYW5kIGFuIG91dHB1dCBpZC4gVGhp cyBpcyBjb25mdXNpbmcgYW5kIHRvbyByZXN0cmljdGl2ZS4gVGhlIHNraU91dHB1dCBmaWVsZCwg aW4gcGFydGljdWxhciwgaXMgdW5jbGVhci4gSXQgdGFsa3MgYWJvdXQgdGhlICppbnB1dCosIGFu ZCByZXBlYXRzIGEgc2VudGVuY2UgZnJvbSB0aGUgc2tpSW5wdXQgZGVmaW5pdGlvbi4NCg0KICAg ICBvIHNraU91dHB1dCBpbmRpY2F0ZXMgdGhlIGtleSBpZGVudGlmaWVyJ3Mgc2VtYW50aWNzLiAg SWYgdGhpcw0KICAgICAgIGZpZWxkIGlzIGFic2VudCwgdGhlbiBrZXkgaWRlbnRpZmllciBpcyB0 aGUgaGFzaCAoYWxnb3JpdGhtDQogICAgICAgaWRlbnRpZmllZCBpbiBraUFsZ29yaXRobSkgb2Yg dGhlIHZhbHVlIG9mIHRoZSBCSVQgU1RSSU5HDQogICAgICAgc3ViamVjdFB1YmxpY0tleSAoZXhj bHVkaW5nIHRoZSB0YWcsIGxlbmd0aCwgYW5kIG51bWJlciBvZiB1bnVzZWQNCiAgICAgICBiaXRz KS4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgT0lEIGlkLXN1YmplY3RQdWJsaWNLZXlJbmZv IHRvDQogICAgICAgYmUgdXNlZCB3aGVuIHRoZSBpbnB1dCB0byB0aGUgaGFzaCBhbGdvcml0aG0g aXMgdGhlIGNlcnRpZmljYXRlJ3MNCiAgICAgICBTdWJqZWN0UHVibGljS2V5SW5mbyBmaWVsZCBb UkZDNTI4MF0uDQoNCg0KDQoNCg0KVHlwb3M6DQoNCjEgIkludHJvZHVjdGlvbiIsIDJuZCBwYXJh Z3JhcGgsIGxhc3Qgc2VudGVuY2UsICIqIiBicmFja2V0cyBjaGFuZ2VzLg0KDQogIEluIGFkZGl0 aW9uLCBzb21lICpzZWN1cml0eSogcHJvdG9jb2xzIChlLmcuLCBTTUlNRSBbUkZDNTc1MV0pDQog ICp1c2Uga2V5IGlkZW50aWZpZXJzKiBhcyBhIHNob3J0aGFuZCB3YXkgdG8gcmVmZXIgdG8gYSBj ZXJ0Lg0KDQozICJTdWJqZWN0IEtleSBpZGVudGlmaWVyIFNlbWFudGljcyBFeHRlbnNpb24iLCAx c3QgYW5kIDJuZCBkb3QgcG9pbnRzLg0KICBXUk9ORyAiYWtpQWxnb3JpdGhtIiBhbmQgImFraUlu cHV0Ig0KICBSSUdIVCAic2tpQWxnb3JpdGhtIiBhbmQgInNraUlucHV0Ig0KDQoNCi0tDQpKYW1l cyBNYW5nZXINCg== From kent@bbn.com Thu Jun 21 07:44:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A75021F86BB for ; Thu, 21 Jun 2012 07:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.396 X-Spam-Level: X-Spam-Status: No, score=-106.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxTdnY4JogGa for ; Thu, 21 Jun 2012 07:44:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AD1F621F86B8 for ; Thu, 21 Jun 2012 07:44:46 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49304) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Shicn-000HLf-HV for pkix@ietf.org; Thu, 21 Jun 2012 10:44:45 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jun 2012 10:33:26 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] agenda topics? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 14:44:47 -0000 Folks, Please send requests for agenda time to Stefan and cc me. Thanks, Steve From kent@bbn.com Thu Jun 21 07:44:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024B021F86F8 for ; Thu, 21 Jun 2012 07:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GPIKBCXZqut for ; Thu, 21 Jun 2012 07:44:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 704AC21F86E8 for ; Thu, 21 Jun 2012 07:44:54 -0700 (PDT) Received: from dhcp89-089-227.bbn.com ([128.89.89.227]:49305) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Shicv-000HM3-Tc for pkix@ietf.org; Thu, 21 Jun 2012 10:44:54 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jun 2012 10:44:52 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] WGLC completed: draft-ietf-pkix-caa-07 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 14:44:56 -0000 Sorry I didn't send this message last week. There is still one discussion ongoing, which I hope will be resolved soon. Steve From turners@ieca.com Thu Jun 21 09:34:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B2A21F875B for ; Thu, 21 Jun 2012 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAYWt+tAsFWg for ; Thu, 21 Jun 2012 09:34:37 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.41.242.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63D21F8754 for ; Thu, 21 Jun 2012 09:34:37 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id D3ECA8D81D0C7; Thu, 21 Jun 2012 11:34:36 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id C926A8D81D0A7 for ; Thu, 21 Jun 2012 11:34:36 -0500 (CDT) Received: from [96.231.119.66] (port=42308 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ShkL6-0007o1-HN; Thu, 21 Jun 2012 11:34:36 -0500 Message-ID: <4FE34D1C.1040704@ieca.com> Date: Thu, 21 Jun 2012 12:34:36 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "Manger, James H" References: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> <4FC6775F.3070206@ieca.com> <4FE09FA0.7070006@ieca.com> <255B9BB34FB7D647A506DC292726F6E114F593B71D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F593B71D@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:42308 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-additional-methods-4kis to ISE X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 16:34:38 -0000 James - thanks for the review. On 6/21/12 3:22 AM, Manger, James H wrote: > A few comments on "Additional methods for key identifiers": > > > Truncation: are the "least significant bits" of a hash the right-most bits? I would have though keeping the leftmost bits was slightly more intuitive. I'll add "(i.e., leftmost)" after "least significant bits". > I think we better put an example in the draft: a SubjectPublicKeyValue; 2 (or 4) subjectKeyId extension values; and 2 (or 4) corresponding ext-skiSemantics values. I'll add a new section: **** This section provides some examples. The keys and key identifiers are presented in hexadecimal (two hex digits per byte). Given the following P-256 ECDSA key: 047F7F35A79794C950060B8029FC8F363A28F11159692D9D34E6AC94819043 4735F833B1A66652DC514337AFF7F5C9C75D670C019D95A5D639B72744C64A 9128BB The SHA-256 hash output of the key is as follows: E72EE6C9C63D2B7F960F0E0611B9800917B5F9494182403EF1BBA8927A57625E Using method 1 in Section 2, the output is truncated as follows: E72EE6C9C63D2B7F960F0E0611B9800917B5F949 This value is then DER-encoded and placed in the SKI's OCTET STRING. The SHA-512 hash output of the key is as follows: 4EF48AB572113ADEC402CC415CF201D5C9969A8A41FE093C1C1D32D67DF66D58 CD2A35607DC4452DF87750663668E2FE197E58A69059618CF0BA9D5C269106E9 Using method 2 in Section, the output is truncated as follows: 4EF48AB572113ADEC402CC415CF201D5C9969A8A This value is then DER-encoded and placed in the SKI's OCTET STRING. ****** > The ext-skiSemantics extension would be better if it held a single AlgorithmIdentifier -- identifying the algorithm used to generate the subject key id. Then the spec can define two such algorithms. > > ext-skiSemantics EXTENSION ::= { > SYNTAX AlgorithmIdentifier > IDENTIFIED BY id-pe-skiSemantics } > > alg-keyHash ALGORITHM ::= { AlgorithmIdentifier IDENTIFIER id-keyHash } > > alg-keyInfoHash ALGORITHM ::= { AlgorithmIdentifier IDENTIFIER id-keyInfoHash } > > alg-keyHash indicates that the key id is the, possibly truncated, hash of > the value of the BIT STRING subjectPublicKey (excluding the tag, length, > and number of unused bits). The amount of truncation can be determined from the > length of the actual key identifier. Truncation keeps the least significant bits > of the hash. The required parameter of this algorithm identifies the hash > algorithm that is used. > > alg-keyInfoHash differs from alg-keyHash in that the hash covers the > key algorithm id in addition to the actual public key. alg-keyInfoHash > indicates that the key id is the, possibly truncated, hash of the > subjectPublicKeyInfo field. The amount of truncation can be determined from the > actual key identifier value. Truncation keeps the least significant bits > of the hash. The required parameter of this algorithm identifies the hash > algorithm that is used. If skiOutput was dumped (see the response below about my horrible c/p error), then this might be a possibility. My objection to the proposed syntax is that the predominant use case I see is where a CA only wants to indicate that it used SHA-256/512 instead of SHA-1 to make the SKI. With the current syntax it collapses to one oid: id-sha256/512 in skiAlgorithm, skiInput and skiOutput are omitted. With the proposed syntax we'd need to carry two oids. > If the spec is going to define alg-keyInfoHash (which it currently does under > the name id-subjectPublicKeyInfo) for the extension (section 3) it really needs > to define it as additional methods for generating key ids (section 2). There's only one there because only one was asked for. I'm willing to add more - got any in mind? > The current model of the extension consists of a hash algorithm, an input id, and an output id. This is confusing and too restrictive. The skiOutput field, in particular, is unclear. It talks about the *input*, and repeats a sentence from the skiInput definition. > > o skiOutput indicates the key identifier's semantics. If this > field is absent, then key identifier is the hash (algorithm > identified in kiAlgorithm) of the value of the BIT STRING > subjectPublicKey (excluding the tag, length, and number of unused > bits). This document defines the OID id-subjectPublicKeyInfo to > be used when the input to the hash algorithm is the certificate's > SubjectPublicKeyInfo field [RFC5280]. Wow now wonder you're confused. An amazingly bad c/p error on my part. Apologies. That last two sentences should be replaced with: If this field is absent, then key identifier is *the output of* the hash (algorithm identified in skiAlgorithm) of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). *That is, it is just like using the 1st key identifier example method in [RFC5280], but instead of using SHA-1 the truncated output of the algorithm in skiAlgorithm is used. This document does not define any OIDs for this field.* Some thought that it would be good to include a field to indicate the semantics of the output. No real examples were given so I've left this one open (i.e., undefined). If anybody's got any suggestions I'd be glad to add it/them. > Typos: > > 1 "Introduction", 2nd paragraph, last sentence, "*" brackets changes. > > In addition, some *security* protocols (e.g., SMIME [RFC5751]) > *use key identifiers* as a shorthand way to refer to a cert. > > 3 "Subject Key identifier Semantics Extension", 1st and 2nd dot points. > WRONG "akiAlgorithm" and "akiInput" > RIGHT "skiAlgorithm" and "skiInput" Fixed both of these thanks. Steve also caught some other typos in the intro. spt From mrex@sap.com Thu Jun 21 14:41:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29221F862F for ; Thu, 21 Jun 2012 14:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7pNo7MY5FCp for ; Thu, 21 Jun 2012 14:41:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C721F8638 for ; Thu, 21 Jun 2012 14:41:05 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q5LLf09I028355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2012 23:41:00 +0200 (MEST) In-Reply-To: <4FE34D1C.1040704@ieca.com> To: Sean Turner Date: Thu, 21 Jun 2012 23:41:00 +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: <20120621214100.8C8EB1A0AD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-additional-methods-4kis to ISE X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2012 21:41:06 -0000 Sean Turner wrote: > > Manger, James H wrote: >> A few comments on "Additional methods for key identifiers": >> >> Truncation: are the "least significant bits" of a hash the >> right-most bits? I would have though keeping the leftmost bits >> was slightly more intuitive. > > I'll add "(i.e., leftmost)" after "least significant bits". "leftmost bits" is also what NIST FIPS 186-3 (Digital Signature Standard) uses for hash output truncation (Section 4.2, page 16): When the length of the output of the hash function is greater than N (i.e., the bit length of q), then the leftmost N bits of the hash function output block shall be used in any calculation using the hash function output during the generation or verification of a digital signature. > > I'll add a new section: > > [...] > > The SHA-256 hash output of the key is as follows: > > E72EE6C9C63D2B7F960F0E0611B9800917B5F9494182403EF1BBA8927A57625E > > Using method 1 in Section 2, the output is truncated as follows: > > E72EE6C9C63D2B7F960F0E0611B9800917B5F949 Yup, an example helps showing truncation to "leftmost bits". -Martin From James.H.Manger@team.telstra.com Thu Jun 21 18:50:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5528B21F85B5 for ; Thu, 21 Jun 2012 18:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h48B2d9wPngC for ; Thu, 21 Jun 2012 18:50:51 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15921F855B for ; Thu, 21 Jun 2012 18:50:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,455,1336312800"; d="scan'208";a="77951429" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 22 Jun 2012 11:50:47 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6749"; a="20188625" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcani.tcif.telstra.com.au with ESMTP; 22 Jun 2012 11:50:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 22 Jun 2012 11:50:46 +1000 From: "Manger, James H" To: "mrex@sap.com" , Sean Turner Date: Fri, 22 Jun 2012 11:50:45 +1000 Thread-Topic: [pkix] draft-turner-additional-methods-4kis to ISE - truncation Thread-Index: Ac1P9pJaUj5PKYrQTu+Hg+o9h8zabgAHkNNQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F59AAB02@WSMSG3153V.srv.dir.telstra.com> References: <4FE34D1C.1040704@ieca.com> <20120621214100.8C8EB1A0AD@ld9781.wdf.sap.corp> In-Reply-To: <20120621214100.8C8EB1A0AD@ld9781.wdf.sap.corp> 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 Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-additional-methods-4kis to ISE - truncation X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 01:50:52 -0000 PiA+IEknbGwgYWRkICIoaS5lLiwgbGVmdG1vc3QpIiBhZnRlciAibGVhc3Qgc2lnbmlmaWNhbnQg Yml0cyIuDQoNClBsZWFzZSBrZWVwICJsZWZ0bW9zdCIsIGJ1dCBjb21wbGV0ZWx5IGRyb3AgImxl YXN0IHNpZ25pZmljYW50Ii4NCkluIGEgREVSLWVuY29kZWQgaW50ZWdlciwgZm9yIGV4YW1wbGUs IHRoZSBsZWFzdCBzaWduaWZpY2FudCBiaXRzIGFyZSB0aGUgcmlnaHRtb3N0IGJpdHMuDQoNCj4g WXVwLCBhbiBleGFtcGxlIGhlbHBzIHNob3dpbmcgdHJ1bmNhdGlvbiB0byAibGVmdG1vc3QgYml0 cyIuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Thu Jun 21 20:32:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD921F84D6 for ; Thu, 21 Jun 2012 20:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjcQkia5GLQj for ; Thu, 21 Jun 2012 20:32:01 -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 1654421F84D0 for ; Thu, 21 Jun 2012 20:32:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,455,1336312800"; d="scan'208";a="81197540" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 22 Jun 2012 13:31:59 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6749"; a="71446944" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdvi.tcif.telstra.com.au with ESMTP; 22 Jun 2012 13:31:54 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Fri, 22 Jun 2012 13:31:42 +1000 From: "Manger, James H" To: Sean Turner Date: Fri, 22 Jun 2012 13:31:41 +1000 Thread-Topic: [pkix] draft-turner-additional-methods-4kis to ISE - example Thread-Index: Ac1Py8Hw+gN8MQ4mQvyKYz98uFJaLgATbN3g Message-ID: <255B9BB34FB7D647A506DC292726F6E114F59AAD21@WSMSG3153V.srv.dir.telstra.com> References: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> <4FC6775F.3070206@ieca.com> <4FE09FA0.7070006@ieca.com> <255B9BB34FB7D647A506DC292726F6E114F593B71D@WSMSG3153V.srv.dir.telstra.com> <4FE34D1C.1040704@ieca.com> In-Reply-To: <4FE34D1C.1040704@ieca.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 Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-additional-methods-4kis to ISE - example X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 03:32:02 -0000 DQo+PiBJIHRoaW5rIHdlIGJldHRlciBwdXQgYW4gZXhhbXBsZSBpbiB0aGUgZHJhZnQ6IGENCj4+ IFN1YmplY3RQdWJsaWNLZXlWYWx1ZTsgMiAob3IgNCkgc3ViamVjdEtleUlkIGV4dGVuc2lvbiB2 YWx1ZXM7IGFuZCAyDQo+PiAob3IgNCkgY29ycmVzcG9uZGluZyBleHQtc2tpU2VtYW50aWNzIHZh bHVlcy4NCj4gDQo+IEknbGwgYWRkIGEgbmV3IHNlY3Rpb246DQo+IA0KPiAqKioqDQo+IA0KPiBU aGlzIHNlY3Rpb24gcHJvdmlkZXMgc29tZSBleGFtcGxlcy4gIFRoZSBrZXlzIGFuZCBrZXkgaWRl bnRpZmllcnMgYXJlDQo+IHByZXNlbnRlZCBpbiBoZXhhZGVjaW1hbCAodHdvIGhleCBkaWdpdHMg cGVyIGJ5dGUpLg0KPiANCj4gR2l2ZW4gdGhlIGZvbGxvd2luZyBQLTI1NiBFQ0RTQSBrZXk6DQo+ IA0KPiAgICAwNDdGN0YzNUE3OTc5NEM5NTAwNjBCODAyOUZDOEYzNjNBMjhGMTExNTk2OTJEOUQz NEU2QUM5NDgxOTA0Mw0KPiAgICA0NzM1RjgzM0IxQTY2NjUyREM1MTQzMzdBRkY3RjVDOUM3NUQ2 NzBDMDE5RDk1QTVENjM5QjcyNzQ0QzY0QQ0KPiAgICA5MTI4QkINCg0KQmV0dGVyIHRvIHN0YXJ0 IHdpdGggYSBTUEtJIHZhbHVlLg0KDQogIEdpdmVuIHRoZSBmb2xsb3dpbmcgREVSLWVuY29kZWQg U3ViamVjdFB1YmxpY0tleUluZm8gdmFsdWUgaG9sZGluZyBhbiBQLTI1NiBFQ0RTQSBrZXk6DQog DQogICAgMzAgNTkNCiAgICAgICAzMCAxMw0KICAgICAgICAgIDA2IDA3IDJBODY0OENFM0QwMjAx ICAgIC0tIGlkLWVjUHVibGljS2V5DQogICAgICAgICAgMDYgMDggMkE4NjQ4Q0UzRDAzMDEwNyAg LS0gc2VjcDI1NnIxDQogICAgICAgMDMgNDIgMDANCiAgICAgICAgICAgICAwNCA3RjdGMzVBNzk3 OTRDOTUwMDYwQjgwMjlGQzhGMzYzQQ0KICAgICAgICAgICAgICAgIDI4RjExMTU5NjkyRDlEMzRF NkFDOTQ4MTkwNDM0NzM1DQogICAgICAgICAgICAgICAgRjgzM0IxQTY2NjUyREM1MTQzMzdBRkY3 RjVDOUM3NUQNCiAgICAgICAgICAgICAgICA2NzBDMDE5RDk1QTVENjM5QjcyNzQ0QzY0QTkxMjhC Qg0KDQogIFRoZSBTSEEtMjU2IGhhc2ggb2YgdGhlIDY1IGJ5dGVzIDA0N0Y3Ri4uLkJCIGlzDQog ICAgQkYzN0IzRTU4MDhGRDQ2RDU0QjI4RTg0NjMxMUJDQ0UxQ0FEMkUxQTYyQUE5MDkyRUYzRUZC M0YxMTQ1MUY0NA0KDQogIFRoZSBTSEEtMSBoYXNoIG9mIHRoZXNlIDY1IGJ5dGVzIGlzDQogICAg NkZFRjkxNjJDMEEzRjJFNzYwODk1NkQ0MUMzN0RBMEM4RTg3RjBBRQ0KDQogIFRoZSBTSEEtMjU2 IGhhc2ggb2YgdGhlIDkxIGJ5dGVzIDMwNTkzMC4uLkJCIGlzDQogICAgNkQyMDg5NkFCOEJEODMz QjZCNjY1NTRCRDU5QjIwMjI1RDhBNzVBMjk2MDg4MTQ4Mzk5RDdCRjc2M0Q1NzQwNQ0KDQoNCiAg VXNpbmcgbWV0aG9kIDEgZnJvbSBzZWN0aW9uIDIsIHRoZSBzdWJqZWN0IGtleSBpZA0KICBleHRl bnNpb24gYW5kIHRoZSBrZXkgaWQgc2VtYW50aWNzIGV4dGVuc2lvbiB3b3VsZCBiZToNCg0KICAg IDMwIDFEDQogICAgICAgMDYgMDMgNTUxRDBFICAtLSBpZC1jZS1zdWJqZWN0S2V5SWRlbnRpZmll cg0KICAgICAgIDA0IDE2DQogICAgICAgICAgMDQgMTQgQkYzN0IzRTU4MDhGRDQ2RDU0QjI4RTg0 NjMxMUJDQ0UxQ0FEMkUxQQ0KICAgDQogICAgMzAgeHgNCiAgICAgICAwNiB4eCB4eHh4eHggIC0t IGlkLXBlLXNraVNlbWFudGljcw0KICAgICAgIDA0IHh4DQogICAgICAgICAgMzAgeHgNCiAgICAg ICAgICAgICAwNiB4eCB4eHh4eHggIC0tIGlkLWtleUhhc2gNCiAgICAgICAgICAgICAwNiAwOSA2 MDg2NDgwMTY1MDMwNDAyMDEgIC0tIGlkLXNoYTI1Ng0KICAgIA0KDQogIFVzaW5nIG1ldGhvZCAx IGZyb20gUkZDNTI4MCB0aGUgdHdvIGV4dGVuc2lvbnMgd291bGQgYmU6DQoNCiAgICAzMCAxRA0K ICAgICAgIDA2IDAzIDU1MUQwRSAgLS0gaWQtY2Utc3ViamVjdEtleUlkZW50aWZpZXINCiAgICAg ICAwNCAxNg0KICAgICAgICAgIDA0IDE0IDZGRUY5MTYyQzBBM0YyRTc2MDg5NTZENDFDMzdEQTBD OEU4N0YwQUUNCiAgIA0KICAgIDMwIHh4DQogICAgICAgMDYgeHggeHh4eHh4ICAtLSBpZC1wZS1z a2lTZW1hbnRpY3MNCiAgICAgICAwNCB4eA0KICAgICAgICAgIDMwIHh4DQogICAgICAgICAgICAg MDYgeHggeHh4eHh4ICAtLSBpZC1rZXlIYXNoDQogICAgICAgICAgICAgMDYgMDUgMkIwRTAzMDIx QSAgLS0gaWQtc2hhMQ0KDQoNCiAgVXNpbmcgbWV0aG9kIDMgZnJvbSBzZWN0aW9uIDIgdGhlIHR3 byBleHRlbnNpb25zIHdvdWxkIGJlOg0KDQogICAgMzAgMUQNCiAgICAgICAwNiAwMyA1NTFEMEUg IC0tIGlkLWNlLXN1YmplY3RLZXlJZGVudGlmaWVyDQogICAgICAgMDQgMTYNCiAgICAgICAgICAw NCAxNCA2RDIwODk2QUI4QkQ4MzNCNkI2NjU1NEJENTlCMjAyMjVEOEE3NUEyDQogICANCiAgICAz MCB4eA0KICAgICAgIDA2IHh4IHh4eHh4eCAgLS0gaWQtcGUtc2tpU2VtYW50aWNzDQogICAgICAg MDQgeHgNCiAgICAgICAgICAzMCB4eA0KICAgICAgICAgICAgIDA2IHh4IHh4eHh4eCAgLS0gaWQt a2V5SW5mb0hhc2gNCiAgICAgICAgICAgICAwNiAwOSA2MDg2NDgwMTY1MDMwNDAyMDEgIC0tIGlk LXNoYTI1NiANCg0KDQo+IA0KPiBUaGUgU0hBLTI1NiBoYXNoIG91dHB1dCBvZiB0aGUga2V5IGlz IGFzIGZvbGxvd3M6DQo+IA0KPiAgICBFNzJFRTZDOUM2M0QyQjdGOTYwRjBFMDYxMUI5ODAwOTE3 QjVGOTQ5NDE4MjQwM0VGMUJCQTg5MjdBNTc2MjVFDQoNCk5vdCBxdWl0ZS4NClRoaXMgaXMgdGhl IFNIQS0yNTYgaGFzaCBvZiB0aGUgMTMwIEFTQ0lJIGhleCBkaWdpdHMsIG5vdCB0aGUgNjUgYnl0 ZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Thu Jun 21 22:46:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2F21F85F4 for ; Thu, 21 Jun 2012 22:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.214 X-Spam-Level: X-Spam-Status: No, score=-1.214 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bD1YrjaDDQR for ; Thu, 21 Jun 2012 22:46:35 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id A863421F85F1 for ; Thu, 21 Jun 2012 22:46:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,455,1336312800"; d="scan'208";a="83988366" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 22 Jun 2012 15:46:32 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6749"; a="72676846" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccni.tcif.telstra.com.au with ESMTP; 22 Jun 2012 15:46:32 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 22 Jun 2012 15:46:32 +1000 From: "Manger, James H" To: Sean Turner Date: Fri, 22 Jun 2012 15:46:30 +1000 Thread-Topic: [pkix] draft-turner-additional-methods-4kis to ISE - SKISemantics Thread-Index: Ac1Py8Hw+gN8MQ4mQvyKYz98uFJaLgAW/F/w Message-ID: <255B9BB34FB7D647A506DC292726F6E114F59AB022@WSMSG3153V.srv.dir.telstra.com> References: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> <4FC6775F.3070206@ieca.com> <4FE09FA0.7070006@ieca.com> <255B9BB34FB7D647A506DC292726F6E114F593B71D@WSMSG3153V.srv.dir.telstra.com> <4FE34D1C.1040704@ieca.com> In-Reply-To: <4FE34D1C.1040704@ieca.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 Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-turner-additional-methods-4kis to ISE - SKISemantics X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 05:46:35 -0000 Pj4gVGhlIGV4dC1za2lTZW1hbnRpY3MgZXh0ZW5zaW9uIHdvdWxkIGJlIGJldHRlciBpZiBpdCBo ZWxkIGEgc2luZ2xlDQo+PiBBbGdvcml0aG1JZGVudGlmaWVyIC0tIGlkZW50aWZ5aW5nIHRoZSBh bGdvcml0aG0gdXNlZCB0byBnZW5lcmF0ZSB0aGUNCj4+IHN1YmplY3Qga2V5IGlkLiBUaGVuIHRo ZSBzcGVjIGNhbiBkZWZpbmUgdHdvIHN1Y2ggYWxnb3JpdGhtcy4NCj4+DQo+PiAgICBleHQtc2tp U2VtYW50aWNzIEVYVEVOU0lPTiA6Oj0gew0KPj4gICAgICBTWU5UQVggQWxnb3JpdGhtSWRlbnRp Zmllcg0KPj4gICAgICBJREVOVElGSUVEIEJZIGlkLXBlLXNraVNlbWFudGljcyB9DQo+Pg0KPj4g ICAgYWxnLWtleUhhc2ggQUxHT1JJVEhNIDo6PQ0KPj4gICAgICB7IEFsZ29yaXRobUlkZW50aWZp ZXIgSURFTlRJRklFUiBpZC1rZXlIYXNoIH0NCj4+DQo+PiAgICBhbGcta2V5SW5mb0hhc2ggQUxH T1JJVEhNIDo6PQ0KPj4gICAgICB7IEFsZ29yaXRobUlkZW50aWZpZXIgSURFTlRJRklFUiBpZC1r ZXlJbmZvSGFzaCB9DQoNCg0KPiBNeSBvYmplY3Rpb24gdG8gdGhlIHByb3Bvc2VkIHN5bnRheCBp cyB0aGF0IHRoZSBwcmVkb21pbmFudCB1c2UgY2FzZSBJDQo+IHNlZSBpcyB3aGVyZSBhIENBIG9u bHkgd2FudHMgdG8gaW5kaWNhdGUgdGhhdCBpdCB1c2VkIFNIQS0yNTYvNTEyDQo+IGluc3RlYWQg b2YgU0hBLTEgdG8gbWFrZSB0aGUgU0tJLiAgV2l0aCB0aGUgY3VycmVudCBzeW50YXggaXQgY29s bGFwc2VzDQo+IHRvIG9uZSBvaWQ6IGlkLXNoYTI1Ni81MTIgaW4gc2tpQWxnb3JpdGhtLCBza2lJ bnB1dCBhbmQgc2tpT3V0cHV0IGFyZQ0KPiBvbWl0dGVkLiAgV2l0aCB0aGUgcHJvcG9zZWQgc3lu dGF4IHdlJ2QgbmVlZCB0byBjYXJyeSB0d28gb2lkcy4NCg0KWWVzLiBZb3UgbmVlZCAyIE9JRHMu IEl0IGFkZHMsIHNheSwgNSBieXRlcyB0byB0aGUgY2VydCBmb3IgYSBsZXNzIGhhY2t5IGRlc2ln bi4gVGhhdCBpcyB3b3J0aCBpdC4NCg0KVGhlIGN1cnJlbnQgc3ludGF4IGFzc3VtZXMgdGhlIG9u bHkgd2F5IHRvIGdlbmVyYXRlIGEga2V5IGlkIGlzIHRvIG11bmdlIHRoZSBoYXNoIG9mIHNvbWV0 aGluZy4gVGhyZWUgT0lEcyBpZGVudGlmeSB0aGUgbXVuZ2luZyAoc2tpT3V0cHV0KSwgdGhlIGhh c2ggKHNraUFsZ29yaXRobSksIGFuZCB0aGUgc29tZXRoaW5nIChza2lJbnB1dCkuIERlZmF1bHRz IGFyZSBnaXZlbiBmb3IgdGhlIG11bmdpbmcgKG9wdGlvbmFsbHkgdHJ1bmNhdGUpIGFuZCB0aGUg c29tZXRoaW5nIChwdWJsaWMga2V5IHZhbHVlKSBzbyBvbmx5IDEgT0lEIGlzIG5lZWRlZCBpbiB0 aGUgImNvbW1vbiIgY2FzZSAod2hpY2ggaXNuJ3QgYWN0dWFsbHkgY29tbW9uIHNpbmNlIFNLSVNl bWFudGljcyBzZWVtcyBsaWtlbHkgdG8gYmUgYSBuaWNoZSBleHRlbnNpb24pLg0KDQpJZiwgZm9y IGluc3RhbmNlLCB0aGUgQ0EgcmFuZG9tbHkgZ2VuZXJhdGVzIHRoZSBrZXkgaWQgaXQgY2Fubm90 IGluZGljYXRlIHRoYXQgLS0gaXQgZG9lc24ndCBmaXQgdGhlIG11bmdlZC1oYXNoLW9mLXNvbWV0 aGluZyBtb2RlbC4gVGhlIENBIHdvdWxkIG5lZWQgdG8gbGllLCBtYWtpbmcgdXAgZmFrZSBoYXNo IGFuZCBpbnB1dCBPSURzIGFuZCBpbmNsdWRpbmcgMyBPSURzIGluIHRoZSBleHRlbnNpb24uDQoN Cg0KPj4gSWYgdGhlIHNwZWMgaXMgZ29pbmcgdG8gZGVmaW5lIGFsZy1rZXlJbmZvSGFzaCAod2hp Y2ggaXQgY3VycmVudGx5DQo+PiBkb2VzIHVuZGVyIHRoZSBuYW1lIGlkLXN1YmplY3RQdWJsaWNL ZXlJbmZvKSBmb3IgdGhlIGV4dGVuc2lvbg0KPj4gKHNlY3Rpb24gMykgaXQgcmVhbGx5IG5lZWRz IHRvIGRlZmluZSBpdCBhcyBhZGRpdGlvbmFsIG1ldGhvZHMNCj4+IGZvciBnZW5lcmF0aW5nIGtl eSBpZHMgKHNlY3Rpb24gMikuDQoNCj4gVGhlcmUncyBvbmx5IG9uZSB0aGVyZSBiZWNhdXNlIG9u bHkgb25lIHdhcyBhc2tlZCBmb3IuICBJJ20gd2lsbGluZyB0bw0KPiBhZGQgbW9yZSAtIGdvdCBh bnkgaW4gbWluZD8NCg0KVGhlIG1ldGhvZHMgZm9yIGdlbmVyYXRpbmcga2V5IGlkcyAoc2VjdGlv biAyIGFuZCBSRkM1MjgwKSwgYW5kIHRoZSB3YXlzIHRvIGlkZW50aWZ5IHRob3NlIG1ldGhvZHMg aW4gYW4gZXh0ZW5zaW9uIChzZWN0aW9uIDMpLCBuZWVkIHRvIGJlIGNvbnNpc3RlbnQuIEF0IHRo ZSBtb21lbnQgdGhleSBhcmUgbm90IGNvbnNpc3RlbnQgc2luY2UgaWQtc3ViamVjdFB1YmxpY0tl eUluZm8gaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMgd2l0aCBub3RoaW5nIGNvcnJlc3BvbmRpbmcg dG8gaXQgYW55d2hlcmUgZWxzZS4NCg0KDQpQLlMuIEluIHRoZSBjdXJyZW50IEFTTi4xIGZvciBT S0lTZW1hbnRpY3MgdGhlIHNraUlucHV0IGFuZCBza2lPdXRwdXQgZmllbGRzIGFyZSBib3RoIE9J RHMgYW5kIGJvdGggT1BUSU9OQUwgc28gdGhleSBuZWVkIHRhZ3MgdG8gZGlzdGluZ3Vpc2ggdGhl bSAoZWcgWzBdIGFuZCBbMV0pLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From anders.rundgren@telia.com Sun Jun 24 02:33:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0D21F85E1 for ; Sun, 24 Jun 2012 02:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i75iwdtVS7UA for ; Sun, 24 Jun 2012 02:33:33 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 68AAD21F85D8 for ; Sun, 24 Jun 2012 02:33:33 -0700 (PDT) Received: from [192.168.0.202] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FD624AF003FA752 for pkix@ietf.org; Sun, 24 Jun 2012 11:33:31 +0200 Message-ID: <4FE6DEEA.7040801@telia.com> Date: Sun, 24 Jun 2012 11:33:30 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] agenda topics? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 09:33:34 -0000 I won't be there but those who are still need to come up with a reasonable explanation to why they propose yet another client-centric certificate enrollment system when essentially all Internet services are server-centric. --anders From anders.rundgren@telia.com Mon Jun 25 04:18:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177B21F847B for ; Mon, 25 Jun 2012 04:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G300GrevfYdy for ; Mon, 25 Jun 2012 04:18:54 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 732B021F84C8 for ; Mon, 25 Jun 2012 04:18:54 -0700 (PDT) Received: from [192.168.0.202] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FD624AF0044C24F for pkix@ietf.org; Mon, 25 Jun 2012 13:18:51 +0200 Message-ID: <4FE84917.3010300@telia.com> Date: Mon, 25 Jun 2012 13:18:47 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Certificate Enrollment Protocols - Gap Analysis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 11:18:55 -0000 - No support for two-factor authentication tokens - No support for security hardware - No support for key algorithm-agility with respect to the enrolling client - No support for external key attributes including logotypes - No support for enrollment process status verification by the issuer - No support for key management - No support for server-based policies - No support for transaction-based enrollments - No support for a standardized browser interface - No support for VPN profiles [1] - No support for "ACL"-like data for keys - No support for symmetric keys Anders 1] Apple has extensive support for VPN profiles in their proprietary iOS solution From pritikin@cisco.com Mon Jun 25 07:02:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B6D21F857F for ; Mon, 25 Jun 2012 07:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5esPDW32aFzV for ; Mon, 25 Jun 2012 07:02:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EE04521F8552 for ; Mon, 25 Jun 2012 07:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1575; q=dns/txt; s=iport; t=1340632932; x=1341842532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3KZSq9wbPagPW4FJKPXM6SqvwFv0k7bnbu3tFXRb09A=; b=Q4gu26cc2G7jE6fyg+NiRKf2j9Fz5lbsYTakk70+25HXFTnoOy7R53cI rH7Mm/WuyL3+AfthvH0egIyJvuQkO1Lnni8WUT9R7HKsunkdxYTV3Wk0C fi1w64LdMnoLUFj7kplvle74rX7su+3EYWREsHLVFAyYOe+xMHxQreUZo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAlv6E+tJXG//2dsb2JhbABEtiuBB4IYAQEBAwEBAQEPASc0CxACAQg2ECcLJQIEDgUbB4dkBQuZBZ9LBIszhSJgA5UujhuBZoJf X-IronPort-AV: E=Sophos;i="4.77,471,1336348800"; d="scan'208";a="95692437" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jun 2012 14:02:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5PE2BYm021321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jun 2012 14:02:11 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.154]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Mon, 25 Jun 2012 09:02:11 -0500 From: "Max Pritikin (pritikin)" To: Anders Rundgren Thread-Topic: [pkix] Certificate Enrollment Protocols - Gap Analysis Thread-Index: AQHNUsRSE8kx5D2XOEa6M2VXG/EdY5cLZIcA Date: Mon, 25 Jun 2012 14:02:10 +0000 Message-ID: <2B53773C-9426-4612-BB1E-AA7AC00C09C2@cisco.com> References: <4FE84917.3010300@telia.com> In-Reply-To: <4FE84917.3010300@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.138] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18994.004 x-tm-as-result: No--28.086800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <37202F2123756343A5310F3B7377F910@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate Enrollment Protocols - Gap Analysis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:02:16 -0000 A terse grenade deserves a terse response: On Jun 25, 2012, at 5:18 AM, Anders Rundgren wrote: > - No support for two-factor authentication tokens false > - No support for security hardware false > - No support for key algorithm-agility with respect to the enrolling clie= nt false > - No support for external key attributes including logotypes false > - No support for enrollment process status verification by the issuer a msg for this has been suggested and we're thinking about the format > - No support for key management false > - No support for server-based policies false. particularly with respect to cert attributes which is being added be= cause a concerned party wrote up their idea and presented it as working tex= t for inclusion. Unlike your suggestions.=20 > - No support for transaction-based enrollments clarification requested. > - No support for a standardized browser interface browser interfaces are for browsers. > - No support for VPN profiles [1] the protocol is extensible and if you'd like to write a draft for this it w= ould be easy to do.=20 > - No support for "ACL"-like data for keys "ACL"-like data is not very well defined. Perhaps you should submit a draft= . > - No support for symmetric keys false Have a great day, - max >=20 > Anders >=20 > 1] Apple has extensive support for VPN profiles in their proprietary iOS = solution >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Mon Jun 25 07:30:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48C321F8649 for ; Mon, 25 Jun 2012 07:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwyiB9zoAW5c for ; Mon, 25 Jun 2012 07:30:57 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id E86A821F8646 for ; Mon, 25 Jun 2012 07:30:56 -0700 (PDT) Received: from [192.168.0.202] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FD624AF00462C07; Mon, 25 Jun 2012 16:30:54 +0200 Message-ID: <4FE8761C.10407@telia.com> Date: Mon, 25 Jun 2012 16:30:52 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Max Pritikin (pritikin)" References: <4FE84917.3010300@telia.com> <2B53773C-9426-4612-BB1E-AA7AC00C09C2@cisco.com> In-Reply-To: <2B53773C-9426-4612-BB1E-AA7AC00C09C2@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Certificate Enrollment Protocols - Gap Analysis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:30:58 -0000 On 2012-06-25 16:02, Max Pritikin (pritikin) wrote: > A terse grenade deserves a terse response: Max, this has little or nothing to do with EST; it's meant to be fairly universal. This is BTW just a summary over the numerous issues I have posted in this list. My take on this is fully covered by published specifications. That doesn't mean that there is only one way of achieving (or even defining) a goal but the alternatives have not been much articulated as far as I can see. There was also a consensus (using IETF norms...) that security hardware is out of scope for PKIX and you did not protest :-) Anyway, most of the listed goals are unreachable using the PKIX "fat-crypto" approach. Security hardware does currently not, and have IMO no reason to ever parse CMS or XML. As an invited expert member of TustedComputingGroup I think I can say (without breaking the NDA...), that it is not on the road-map for these guys either. Best Anders > > On Jun 25, 2012, at 5:18 AM, Anders Rundgren wrote: > >> - No support for two-factor authentication tokens > false > >> - No support for security hardware > false > >> - No support for key algorithm-agility with respect to the enrolling client > false > >> - No support for external key attributes including logotypes > false > >> - No support for enrollment process status verification by the issuer > a msg for this has been suggested and we're thinking about the format > >> - No support for key management > false > >> - No support for server-based policies > false. particularly with respect to cert attributes which is being added because a concerned party wrote up their idea and presented it as working text for inclusion. Unlike your suggestions. > >> - No support for transaction-based enrollments > clarification requested. > >> - No support for a standardized browser interface > browser interfaces are for browsers. > >> - No support for VPN profiles [1] > the protocol is extensible and if you'd like to write a draft for this it would be easy to do. > >> - No support for "ACL"-like data for keys > "ACL"-like data is not very well defined. Perhaps you should submit a draft. > >> - No support for symmetric keys > false > > Have a great day, > > - max > >> >> Anders >> >> 1] Apple has extensive support for VPN profiles in their proprietary iOS solution >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > From kent@bbn.com Mon Jun 25 11:44:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D147911E80AA for ; Mon, 25 Jun 2012 11:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQmSAvFPuoMJ for ; Mon, 25 Jun 2012 11:44:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3A11E80A1 for ; Mon, 25 Jun 2012 11:44:31 -0700 (PDT) Received: from dhcp-192-1-255-188.col.bbn.com ([192.1.255.188]:49161) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SjEGM-000Lcs-PH; Mon, 25 Jun 2012 14:43:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4FE6DEEA.7040801@telia.com> References: <4FE6DEEA.7040801@telia.com> Date: Mon, 25 Jun 2012 14:44:27 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] agenda topics? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:44:31 -0000 At 11:33 AM +0200 6/24/12, Anders Rundgren wrote: >I won't be there but those who are still need to come up with >a reasonable explanation to why they propose yet another >client-centric certificate enrollment system when essentially >all Internet services are server-centric. > >--anders > Anders, The subject of the message who a request for slots. Since, as you noted, you are not attending, you need not reply. Also, your repeated messages about what you think are the most important problems to be addressed, accompanied by no I-Ds, are not helpful. If you persist in such postings, I'll remove you form the list. Clear? Steve From anders.rundgren@telia.com Mon Jun 25 22:28:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF1921F8501 for ; Mon, 25 Jun 2012 22:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AbRzjENNL-N for ; Mon, 25 Jun 2012 22:28:22 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3C19E21F84FF for ; Mon, 25 Jun 2012 22:28:22 -0700 (PDT) Received: from [192.168.0.202] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FA80EAF010F640E; Tue, 26 Jun 2012 07:28:15 +0200 Message-ID: <4FE9486B.60203@telia.com> Date: Tue, 26 Jun 2012 07:28:11 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stephen Kent References: <4FE6DEEA.7040801@telia.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] agenda topics? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 05:28:23 -0000 On 2012-06-25 20:44, Stephen Kent wrote: > At 11:33 AM +0200 6/24/12, Anders Rundgren wrote: >> I won't be there but those who are still need to come up with >> a reasonable explanation to why they propose yet another >> client-centric certificate enrollment system when essentially >> all Internet services are server-centric. >> >> --anders >> > > Anders, > > The subject of the message who a request for slots. Since, as you noted, > you are not attending, you need not reply. > > Also, your repeated messages about what you think are the most > important problems to be addressed, accompanied by no I-Ds, are not > helpful. If you persist in such postings, I'll remove you form the > list. Clear? Steve, If it makes you happy, feel free removing me from the list. My only intent was trying to ignite an interest in creating a credential enrollment standard for the *mass-market*. Since we didn't even managed getting an *open discussion on the requirements*, the PKI-using-community essentially has nothing to do but waiting for Google to present a de-facto standard. I guess it will come somewhere between Android V5 and V6. Right, Wan-Teh? :-) This might actually be a better idea [1] than investing in 150p+ difficult-to-read I-Ds that may never be adopted by the platform vendors. Regarding CMC/SCEP/CMP/EST they are all based on what I call "Fat Crypto". This is (as I have described in great length), incompatible with E2ES (End-to-End Security) and security hardware. Security hardware is already available in many popular Android devices, is announced for Windows Phone 8, and rumored to be a part of iPhone 5. Anders 1] The IETF KEYPROV effort which several PKIXers participated in, took forever and didn't go anywhere. Protocol standardization is indeed a daunting task. > > Steve > From paul.hoffman@vpnc.org Tue Jun 26 07:48:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31AF21F85F7 for ; Tue, 26 Jun 2012 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU1GDCjfxNbW for ; Tue, 26 Jun 2012 07:48:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6792821F85D1 for ; Tue, 26 Jun 2012 07:48:34 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5QEmReQ005466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jun 2012 07:48:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FE9486B.60203@telia.com> Date: Tue, 26 Jun 2012 07:48:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE6DEEA.7040801@telia.com> <4FE9486B.60203@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1278) Cc: pkix@ietf.org Subject: Re: [pkix] agenda topics? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:48:44 -0000 On Jun 25, 2012, at 10:28 PM, Anders Rundgren wrote: > My only intent was trying to ignite an interest in creating a > credential enrollment standard for the *mass-market*. If that is your intention, why do you refuse to back it up with any = action? There is no way for the community to assess whether or not your = idea is viable without seeing a concrete proposal for it. > 1] The IETF KEYPROV effort which several PKIXers participated in, took = forever > and didn't go anywhere. Protocol standardization is indeed a daunting = task. It is made more daunting by people who believe that they should = "contribute" only by spewing ideas and not doing any real work. AFAICT, = you are in that category; I would love to be proven wrong. --Paul Hoffman From internet-drafts@ietf.org Tue Jun 26 08:40:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2421F85F8; Tue, 26 Jun 2012 08:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlFbkrxhlODg; Tue, 26 Jun 2012 08:40:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825B121F85CD; Tue, 26 Jun 2012 08:40:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120626154038.26642.3656.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 08:40:38 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-08.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:40:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-08.txt Pages : 16 Date : 2012-06-25 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-caa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-caa-08 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-caa-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From anders.rundgren@telia.com Tue Jun 26 08:42:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A8621F84FE for ; Tue, 26 Jun 2012 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWbhX5dEEQLY for ; Tue, 26 Jun 2012 08:42:37 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 92FBD21F84FB for ; Tue, 26 Jun 2012 08:42:37 -0700 (PDT) Received: from [192.168.0.202] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FA80EAF01139804; Tue, 26 Jun 2012 17:42:26 +0200 Message-ID: <4FE9D85D.1050009@telia.com> Date: Tue, 26 Jun 2012 17:42:21 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4FE6DEEA.7040801@telia.com> <4FE9486B.60203@telia.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] agenda topics? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:42:38 -0000 On 2012-06-26 16:48, Paul Hoffman wrote: > On Jun 25, 2012, at 10:28 PM, Anders Rundgren wrote: > >> My only intent was trying to ignite an interest in creating a >> credential enrollment standard for the *mass-market*. > > If that is your intention, why do you refuse to back it up with any action? > There is no way for the community to assess whether or not your idea is viable > without seeing a concrete proposal for it. OK... I have provided links to 70p+ of *very detailed* specifications plus a number of "executive level" slide-shows as well. I would estimate that the total effort including supporting code is about 3000 hours over a period of 5 calendar-years. No, I didn't write an I-D because that would be pointless without first having requirement discussions. The latter died pretty immediately when I mentioned End-2-End Security, Embedded Security Hardware, PIN-code Deployment and Browser Interfaces. Established PKI applications rely since years back on SCEP, CMP, and CMC and doesn't seem to be in great need for a new standard. This is the reason why I suggested targeting *unestablished* but "promising" applications like Mobile Payments, Virtual SIM-cards and Consumer-PKI in general. I also find the mere idea of creating security applications [1] for people who have no interest or knowledge about such, both challenging and fun :-) Anyway, this is history, at least for PKIX. Cheers, Anders 1] I don't characterize SKS/KeyGen2 as a security application, but as an IT-solution where security is a component among other. > >> 1] The IETF KEYPROV effort which several PKIXers participated in, took forever >> and didn't go anywhere. Protocol standardization is indeed a daunting task. > > > It is made more daunting by people who believe that they should "contribute" only by spewing ideas and not doing any real work. AFAICT, you are in that category; I would love to be proven wrong. > > --Paul Hoffman > > From turners@ieca.com Thu Jun 28 05:52:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19A21F854F for ; Thu, 28 Jun 2012 05:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiIAzVdUc+3a for ; Thu, 28 Jun 2012 05:51:59 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.66.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8721F854D for ; Thu, 28 Jun 2012 05:51:59 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 0B12C9BA15292; Thu, 28 Jun 2012 07:51:59 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id F19689BA15246 for ; Thu, 28 Jun 2012 07:51:58 -0500 (CDT) Received: from [96.231.119.66] (port=44362 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SkECU-0005nV-HG; Thu, 28 Jun 2012 07:51:58 -0500 Message-ID: <4FEC536D.5060506@ieca.com> Date: Thu, 28 Jun 2012 08:51:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120612014622.06FA9B1E002@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:44362 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 14 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= X-Mailman-Approved-At: Thu, 28 Jun 2012 09:19:55 -0700 Cc: cadams@entrust.com, stefan@aaa-sec.com, rankney@erols.com, ambarish@valicert.com, mmyers@verisign.com, dsb@smart.net, galperin@mycfo.com Subject: Re: [pkix] [Editorial Errata Reported] RFC2560 (3253) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 12:52:00 -0000 I'm going to mark all three of theses Hold For Document Update. spt On 6/12/12 10:42 AM, Michael Myers wrote: > I have no problems with the three errata just cited. > > Michael Myers > > > > On Jun 11, 2012, at 6:46 PM, RFC Errata System wrote: > >> >> The following errata report has been submitted for RFC2560, >> "X.509 Internet Public Key Infrastructure Online Certificate Status >> Protocol - OCSP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=2560&eid=3253 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Daniel Barclay >> >> Section: 5 >> >> Original Text >> ------------- >> For this service to be effective, certificate using systems must >> connect to >> the certificate status service provider. >> >> Corrected Text >> -------------- >> For this service to be effective, certificate-using systems must >> connect to >> the certificate status service provider. >> >> Notes >> ----- >> (Alternatively, that could be "..., systems using certificates must ..." >> >> 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. >> >> -------------------------------------- >> RFC2560 (draft-ietf-pkix-ocsp-07) >> -------------------------------------- >> Title : X.509 Internet Public Key Infrastructure Online >> Certificate Status Protocol - OCSP >> Publication Date : June 1999 >> Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. >> Adams >> Category : PROPOSED STANDARD >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > From internet-drafts@ietf.org Fri Jun 29 21:54:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4A821F866D; Fri, 29 Jun 2012 21:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn-clhnIcYmi; Fri, 29 Jun 2012 21:54:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440AA21F865C; Fri, 29 Jun 2012 21:54:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120630045423.3301.66634.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2012 21:54:23 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-05.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 04:54:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Updates to the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile Author(s) : Peter E. Yee Filename : draft-ietf-pkix-rfc5280-clarifications-05.txt Pages : 9 Date : 2012-06-29 Abstract: This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc5280-clarifications= -05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From peter@akayla.com Fri Jun 29 21:58:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4721F849D for ; Fri, 29 Jun 2012 21:58:03 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq5Q-AdzTLVc for ; Fri, 29 Jun 2012 21:58:02 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by ietfa.amsl.com (Postfix) with SMTP id AF15421F849C for ; Fri, 29 Jun 2012 21:58:02 -0700 (PDT) Received: (qmail 3760 invoked from network); 30 Jun 2012 04:58:02 -0000 Received: from unknown (173.8.184.78) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 30 Jun 2012 04:58:02 -0000 From: "Peter Yee" To: "'Stephen Kent'" , References: In-Reply-To: Date: Fri, 29 Jun 2012 21:58:04 -0700 Message-ID: <033201cd567c$ef626970$ce273c50$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJEMV1dE1bhb40fkyymPD3aKbJww5Ykls3g Content-Language: en-us Subject: Re: [pkix] new version of 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 04:58:04 -0000 The updated draft has been posted. Please let me know if further changes are required. Thanks. -Peter -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, June 19, 2012 8:18 AM To: pkix@ietf.org Subject: [pkix] new version of 5280 clarifications A new version of 5280 clarifications will be published shortly. Peter Yee has taken over from David Copper as the document editor. There are very few changes since the last published version. The only major change is a new paragraph on our favorite topic of self-signed EE certs. Hopefully this text will be acceptable. Steve _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix