Subject: Re: [pkix] RFC2560bis update - CertHash extension

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 Jul 2012 16:22:29 +0200

Hi Peter,

My first though about this is that such extension should go into a separate
specification and not be included in the base specification, unless it is so
widely used that is ought to go into the main spec.

I would like to hear from others.
I changed the title of the thread for discussion of this particular issue.

/Stefan

From:  Peter Rybar <[email-masked]>
Date:  Monday, 23 July, 2012 3:12 PM
To:  Stefan Santesson <[email-masked]>, 'Sean Turner'
<[email-masked]>, <[email-masked]>, <[email-masked]>
Cc:  <[email-masked]>, <[email-masked]>
Subject:  RE: [pkix] RFC2560bis update

> All,
>  
> Is it possible to include already defined and widely used CertHash OCSP
> SingleResponse singleExtensions used as Positive Statement?
>  
> RFC 2560 in part "2.2  Response" expects positive statement to be used but it
> is not defined in RFC 2560.
> " The "good" state indicates a positive response to the status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued or that the time at which the response was produced
>    is within the certificate's validity interval. Response extensions
>    may be used to convey additional information on assertions made by
>    the responder regarding the status of the certificate such as
>    positive statement about issuance, validity, etc. "
>  
> The CertHashextension (Positive Statement) is used in indirect OCSP response
> as a positive statement that OCSP responder knows the status of the
> certificate and also provides the integrity protectionof the certificate if
> the certificate is already expired and algorithms used in the certificate
> could be weak. The CertHash extension (Positive Statement) adopted from Common
> PKI Optional SigG-Profile is designed to be included in the OCSP
> singleExtensions of SingleResponse(RFC 2560).
>  
>    Common PKI Object Identifiers:     1.3.36.8.3.13
>  
>   CertHash ::= SEQUENCE {
>       hashAlgorithm AlgorithmIdentifier,
>                  -- The identifier of the algorithm that has been used
>                  -- the hash value below.
>       certificateHash OCTET STRING
>                  -- The hash over DER-encoding of the entire PKC or AC
>                            --   (i.e. NOT a hash over tbsCertificate).
>   }
>  
> It is on the page 9 in the presentation.
> http://files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of%20th
> e%20Conference%20June%2004-06th%202012%20Poland.ppt
>  
> There is also experimental extension which is on the page 10.
>  
> The OCSP response with ProofOfExistence extension of signer¹s signature can be
> used as a secure time-mark with the same functionality as expected from the
> signature time stamp. The ProofOfExistence extension is designed to be
> included in the singleRequestExtensions of OCSP(RFC 2560) and the same
> ProofOfExistence must be included in the singleExtensions of
> SingleResponse(RFC 2560).
>  
>  Object Identifiers: 1.3.6.1.4.1.38655.1.4
>       ProofOfExistence ::=  SEQUENCE {
>            poEType  PoEType DEFAULT poESignerSignatureBinOctets,
>            poE MessageImprint
>        }
>        PoEType ::=  INTEGER  { poESignerSignatureBinOctets(0), poEAnyDATA(1) }
>        
>        MessageImprint ::= SEQUENCE  {    -- MessageImprint is defined in RFC
> 3161
>            hashAlgorithm               AlgorithmIdentifier,
>            hashedMessage                OCTET STRING
>        }
>  
>  
> Pete Rybar
>  
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan
> Santesson
> Sent: Monday, July 23, 2012 12:12 PM
> To: Sean Turner
> Cc: [email-masked]
> Subject: Re: [pkix] RFC2560bis update
>  
> Sean,
>  
> Good point,
>  
> I actually forgot to process the erratas. I'll go ahead and do that and
> will put up a new version.
>  
> /Stefan
>  
> On 12-07-23 5:14 AM, "Sean Turner" <[email-masked]> wrote:
>  
>> >Stefan,
>> > 
>> >In terms of figuring out what's changed in the draft, this version is
>> >much easier to follow.
>> > 
>> >The addition of the list of changes was definitely a good idea
>> >(definitely saved yourself a comment from me during AD review).
>> > 
>> >I haven't checked this but did you incorporate the verified errata and
>> >considered the HFDU (hold for document update) errata?
>> > 
>> >spt
>> > 
>> >On 7/20/12 1:07 PM, Stefan Santesson wrote:
>>> >> All,
>>> >> 
>>> >> I finally got to tackle the update of RFC2560bis document.
>>> >> 
>>> >> At the last ITEF/PKIX meeting we concluded that this effort needs a
>>> >>restart.
>>> >> The changes in the 04 draft compared to the original document are so
>>> >> extensive that it is hard to make sure that the update is actually
>>> >> compatible with the existing standard.
>>> >> 
>>> >> I have therefore made a new draft almost from scratch, trying to change
>>> >> as little as possible compared to RFC 2560.
>>> >> 
>>> >> The new draft is available here:
>>> >> http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_02.txt
>>> >> 
>>> >> A diff compared to RFC 2560 is available here:
>>> >> http://tinyurl.com/rfc2560bis05diff
>>> >> 
>>> >> The list of changes (this list is included in the draft) is:
>>> >> 
>>> >> This document differs from RFC 2560 in only a few areas:
>>> >> 
>>> >>     o  Section 4.1.1 specifies the ASN.1 syntax for the nonce
>>> >>        extension, which was missing in RFC 2560.
>>> >> 
>>> >>     o  Section 4.4.7 specifies a new extension that may be included in
>>> >>        a request message to specify signature algorithms the client
>>> >>        would prefer the server use to sign the response as specified
>>> >>        in [RFC6277].
>>> >> 
>>> >>     o  Section 2.3 extends the use of the "unauthorized" error
>>> >>        response, as specified in [RFC5019].
>>> >> 
>>> >>     o  Section 4.2.1 and 4.2.2.3 states that a response may include
>>> >>        revocation status information for certificates that were not
>>> >>        included in the request, as permitted in [RFC5019].
>>> >> 
>>> >>     o  Section 4.3 changes set of cryptographic algorithms that
>>> >>        clients must support and the set of cryptographic algorithms
>>> >>        that clients should support as specified in [RFC6277].
>>> >> 
>>> >>     o Section 4.2.2.2 has been updated to clarify when a responder is
>>> >>        considered an Authorized Responder.
>>> >> 
>>> >> 
>>> >> 
>>> >> Section headings and numbering are as much as possible kept intact from
>>> >> RFC 2560.
>>> >> The ASN-1 modules are imported form rfc2560bis draft 04.
>>> >> 
>>> >> What important updates did I miss to cover in this draft?
>>> >> 
>>> >> If this is considered a good starting point for a restarted draft
>>> >> effort, then I will publish this as draft 05 as soon as the draft
>>> >> submission is re-opened.
>>> >> 
>>> >> /Stefan
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>>> >> 
>  
>  
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 23 Jul 2012 18:23:57 +0200

This extension is not "widely used" and should be discussed separately.
I've never encountered it in any of the big CAs; I wanted to check for CAs
based in Slovakia but haven't found any OCSP responder to query.

2012/7/23 Stefan Santesson <[email-masked]>

> Hi Peter,
>
> My first though about this is that such extension should go into a
> separate specification and not be included in the base specification,
> unless it is so widely used that is ought to go into the main spec.
>
> To: Stefan Santesson <[email-masked]>, 'Sean Turner' <[email-masked]>,
> <[email-masked]>, <[email-masked]>
> **
> All,****
> ** **
> SingleResponse singleExtensions used as Positive Statement? ****
>
> ** **
>
> RFC **2560 in** part "2.2  Response" expects positive statement to be
> used but it is not defined in RFC 2560.****
>
> " The "good" state indicates a positive response to the status inquiry.***
> *
>
>    At a minimum, this positive response indicates that the certificate****
>
>    is not revoked, *but does not necessarily mean that the certificate*
>
> *   was ever issued or that the time at which the response was produced*
>
> *   is within the certificate's validity interval*. *Response extensions*
>
> *   may be used to convey additional information on assertions made by*
>
> *   the responder regarding the status of the certificate such as*
>
> *   positive statement about issuance, validity, etc.* "****
>
> ** **
>
> The *CertHash**extension* (Positive Statement) is used in indirect OCSP
> response as a positive statement that OCSP responder *knows the status*of the certificate and also provides the
> *integrity protection**of* the certificate if the *certificate is already
> expired* and *algorithms* used in the certificate *could be weak*. The *
> CertHash* *extension* (Positive Statement) adopted from Common PKI
> Optional SigG-Profile is designed to be included in the OCSP
> singleExtensions of SingleResponse(RFC 2560). ****
>
> ** **
>
>    Common PKI Object Identifiers:     1.3.36.8.3.13****
>
> ** **
>
>   CertHash ::= SEQUENCE {****
>
>       hashAlgorithm AlgorithmIdentifier,****
>
>                  -- The identifier of the algorithm that has been used ***
> *
>
>                  -- the hash value below.****
>
>       certificateHash OCTET STRING****
>
>                  -- The hash over DER-encoding of the entire PKC or AC ***
> *
>
>                            --   (i.e. NOT a hash over tbsCertificate).****
>
>   }****
>
> ** **
>
> It is on the page **9 in** the presentation.****
>
>
> http://files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of%20the%20Conference%20June%2004-06th%202012%20Poland.ppt
> ****
>
> ** **
>
> There is also experimental extension which is on the page 10.****
>
> ** **
>
> The OCSP response with *ProofOfExistence* extension of signer’s signature
> can be used as a secure time-mark with the *same functionality *as
> expected from* the signature time stamp*. The ProofOfExistence extension
> is designed to be included in the singleRequestExtensions of OCSP(RFC 2560)
> and the same ProofOfExistence must be included in the singleExtensions of
> SingleResponse(RFC 2560). ****
>
> ** **
>
>  Object Identifiers: 1.3.6.1.4.1.38655.1.4****
>
>       ProofOfExistence ::=  SEQUENCE {****
>
>            poEType  PoEType DEFAULT poESignerSignatureBinOctets,****
>
>            poE MessageImprint****
>
>        }****
>
>        PoEType ::=  INTEGER  { poESignerSignatureBinOctets(0),
> poEAnyDATA(1) }****
>
>        ****
>
>        MessageImprint ::= SEQUENCE  {    -- MessageImprint is defined in
> RFC 3161****
>
>            hashAlgorithm                AlgorithmIdentifier,****
>
>            hashedMessage                OCTET STRING****
>
>        }****
>
> ** **
>
> ** **
>
> Pete Rybar****
>
> ** **
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Stefan Santesson
> Subject: Re: [pkix] RFC2560bis update****
>
> ** **
>
> Sean,****
>
> ** **
>
> Good point,****
>
> ** **
>
> I actually forgot to process the erratas. I'll go ahead and do that and***
> *
>
> will put up a new version.****
>
> ** **
>
> /Stefan****
>
> ** **
>
> On 12-07-23 5:14 AM, "Sean Turner" <[email-masked]> wrote:****
>
> ** **
>
> >Stefan,****
>
> >** **
>
> >In terms of figuring out what's changed in the draft, this version is****
>
> >much easier to follow.****
>
> >** **
>
> >The addition of the list of changes was definitely a good idea****
>
> >(definitely saved yourself a comment from me during AD review).****
>
> >** **
>
> >I haven't checked this but did you incorporate the verified errata and***
> *
>
> >considered the HFDU (hold for document update) errata?****
>
> >** **
>
> >spt****
>
> >** **
>
> >On 7/20/12 1:07 PM, Stefan Santesson wrote:****
>
> >> All,****
>
> >>** **
>
> >> I finally got to tackle the update of RFC2560bis document.****
>
> >>** **
>
> >> At the last ITEF/PKIX meeting we concluded that this effort needs a****
>
> >>restart.****
>
> >> The changes in the 04 draft compared to the original document are so***
> *
>
> >> extensive that it is hard to make sure that the update is actually****
>
> >> compatible with the existing standard.****
>
> >>** **
>
> ****
> >> as little as possible compared to RFC 2560.****
>
> >>** **
>
> >> The new draft is available here:****
>
> ****
> >>** **
> >> A diff compared to RFC 2560 is available here:****
>
> >> http://tinyurl.com/rfc2560bis05diff****
>
> >>** **
>
> >> The list of changes (this list is included in the draft) is:****
>
> >>** **
>
> >> This document differs from RFC **2560 in** only a few areas:****
>
> >>** **
>
> >>     o  Section 4.1.1 specifies the ASN.1 syntax for the nonce****
>
> >>        extension, which was missing in RFC 2560.****
>
> >>** **
>
> >>     o  Section 4.4.7 specifies a new extension that may be included in*
> ***
>
> >>        a request message to specify signature algorithms the client****
>
> >>        would prefer the server use to sign the response as specified***
> *
>
> >>        in [RFC6277].****
>
> >>** **
>
> >>     o  Section 2.3 extends the use of the "unauthorized" error****
>
> >>        response, as specified in [RFC5019].****
>
> >>** **
>
> >>     o  Section 4.2.1 and 4.2.2.3 states that a response may include****
>
> >>        revocation status information for certificates that were not****
>
> >>        included in the request, as permitted in [RFC5019].****
>
> >>** **
>
> >>     o  Section 4.3 changes set of cryptographic algorithms that****
>
> >>        clients must support and the set of cryptographic algorithms****
>
> >>        that clients should support as specified in [RFC6277].****
>
> >>** **
>
> >>     o Section 4.2.2.2 has been updated to clarify when a responder is**
> **
>
> >>        considered an Authorized Responder.****
>
> >>** **
>
> >>** **
>
> >>** **
>
> ****
> >> RFC 2560.****
> >> The ASN-1 modules are imported form rfc2560bis draft 04.****
>
> >>** **
>
> >> What important updates did I miss to cover in this draft?****
>
> >>** **
>
> >> If this is considered a good starting point for a restarted draft****
>
> >> effort, then I will publish this as draft 05 as soon as the draft****
>
> >> submission is re-opened.****
>
> >>** **
>
> >> /Stefan****
>
> >>** **
>
> >>** **
>
> >>** **
>
> >>** **
>
> >>** **
>
> >>** **
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> pkix mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/pkix****
> **
>
>

-- 
Erwann.