Subject: Re: PKIX notice files, and markup

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Mar 1999 12:04:52 +0100

While trying to implement dcs it was obvious that some
small changes became necessary: including some obvious
asn.1 syntax corrections, the following resumes changes
that I propose. 

The only non obvious piece the replacement of a certificate
list by a sequence of target and chain in the response.

This can be used properly for example in a cpkc request:

The requester enters a liste of certs to be validated, 
and the response includes for each cert a chain or a
list of certs that are somehow related to that cert, and
the policy information that was used. 

Peter

ReqInfo ::= SEQUENCE  {
     version                      Integer ,
     service                      ServiceType,
     requester                    [0] GeneralName OPTIONAL,
     reqPolicy                    [1] PolicyInformation OPTIONAL,
     dcs                          [2] GeneralName ,
     nonce                        Integer,
     reqTime                      ReqTime OPTIONAL,
     extensions                   Extensions OPTIONAL   
}

TargetandChain ::= SEQUENCE {
     target                       Certificate,
     chain                        [0] SEQUENCE OF Certificate OPTIONAL,
     pathProcInput                [1] PathProcInput OPTIONAL  
}

Info ::= SEQUENCE  {
     reqInfo                ReqInfo,
       messageImprint               MessageImprint,
     reqSignature             [0]    SignerInfo OPTIONAL,
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     time                         ReqTime, 
     serialNumber                 Integer OPTIONAL,
     chainCerts              [1]  SEQUENCE OF TargetandChain OPTIONAL, 
     crls                    [2]  SEQUENCE OF Certificate OPTIONAL,
     extensions               [3]    Extensions OPTIONAL  
}

PathProcInput ::= SEQUENCE {
     acceptablePolicySet          CertificatePolicies ,
     inhibitPolicyMapping         [0] BOOLEAN DEFAULT FALSE,
     explicitPolicyReqd           [1] BOOLEAN DEFAULT FALSE 
}

> 
> The approach can be used also for DCS.
> 
> Peter.
> 
> 
> 
>

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 26 Apr 1999 11:16:58 -0500

-----Original Message-----
From: Russ Housley <[email-masked]>
To: Peter Williams <[email-masked]>
Cc: IETF-PXIX <[email-masked]>
Date: Friday, March 26, 1999 10:20 AM
Subject: Re: PKIX notice files, and markup

>Peter:
>
>The ASN.1 types limit some choices, although DisplayText provides alot of
>flexibility.
>
>Russ
>

Are you suggesting that the notice file content is limited to DisplayText,
like the 200 chars of embedded notice content is so limited?

The original intent of the design was that the notice file would
have an (unspecified) compound document architecture with referencable
elements, so that certs could function as notice-deliving vehicles
in trade-terms protocols conducted via the negotiation and interchange of
certs
in SSL and IKE  handshakes. The implicitely embedded legal terms
and conditions are an important part of trade negotiation, assuming certs
are to serve as the backbone for interactive commerce, not merely
a boring network security and authentication infrastructure replacing
kerberos.

It is true today's first implementation of this is used to send threatening
and dire
CPS warnings to browser users, as a minimal notice protocol. And that use
could perhaps be limited to a simple string.  But that was not
the limited purpose of the design which has much potential, now the
mechanism is standardized.